MID Server를 수동으로 업그레이드하거나 인스턴스를 통해 자동으로 업그레이드합니다. 인스턴스가 업그레이드되고 MID 서버의 버전이 더 이상 동일하지 않을 때 MID 서버 자동 업그레이드가 트리거됩니다. 새 MID Server 패키지가 install.service-now.com 에서 다운로드되어 이전 패키지를 대체하며 MID Server는 새 버전으로 시작됩니다.

경고: Windows 애플리케이션 경험 서비스가 꺼져 있으면 MID 서버가 Windows 호스트에서 자동 업그레이드될 수 없습니다. 표시되는 오류에 대한 자세한 내용과 이 서비스를 다시 사용하도록 설정하는 방법에 대한 지침은 KB0597552 참조하십시오.

MID 서버 업그레이드 요구 사항

MID Server 다운로드 사이트에 대한 액세스
MID 서버 호스트 컴퓨터가 자동으로 업그레이드되려면 install.service-now.com 에서 ServiceNow 다운로드 사이트에 액세스할 수 있어야 합니다. 다운로드 사이트에 대한 액세스를 차단하는 자체 호스팅 ServiceNow 환경이 있는 경우 MID Server 설치 프로그램 패키지를 MID Server 호스트로 수동으로 임포트해야 합니다. 자세한 내용은 자체 호스팅 기술 자료의 KB0760123 참조하십시오.
OCSP에 대한 MID 서버 액세스 차단됨
방화벽과 프록시 구성이 OCSP, Entrust 및 DigiCert 서버에 대한 호출을 차단하여 MID 서버가 작동하지 않을 수 있습니다. OCSP 트래픽이 통과할 수 있도록 방화벽 권한을 변경해야 할 수 있습니다. 자세한 정보 및 해결 방법은 HI 지식베이스 문서 [KB1216223]을 참조하십시오.
MID 서버 운영 체제 호환성
32비트 운영 체제를 사용하는 Windows 또는 Linux MID 서버의 업그레이드는 지원되지 않습니다. 자세한 내용은 [KB0863694] 문서를 참조하십시오.

Windows 애플리케이션 경험 서비스가 꺼져 있으면 MID 서버가 Windows 호스트에서 업그레이드될 수 없습니다. 표시되는 오류에 대한 자세한 내용과 이 서비스를 다시 사용하도록 설정하는 방법에 대한 지침은 KB0597552 참조하십시오.

MID Server 업그레이드는 Windows 호스트에서 실행되는 일부 바이러스 백신에 의해 차단됩니다. 이러한 바이러스 백신의 오류 및 목록에 대한 자세한 내용은 KB0870329 참조하십시오.

서비스가 마드리드 이하의 시스템에 설치된 모든 Linux MID 서버 업그레이드는 업그레이드 후 서비스를 다시 설치해야 합니다. 이전 업그레이드에서 서비스를 수동으로 다시 설치하지 않았고 MID 서버 서비스가 여전히 Madrid 이하 버전에 설치되어 있는 경우 업그레이드 중에 MID 서버가 자동으로 서비스를 다시 설치합니다. 서비스를 다시 설치하려면 MID 서버를 관리자 사용자로 실행해야 합니다. MID 서버 업그레이드 시 서비스를 다시 설치해야 하는 경우 MID 서버 사용자가 관리자인지 확인하거나 업그레이드 전에 서비스를 수동으로 다시 설치할 수 있습니다. 서비스를 수동으로 다시 설치하는 방법에 대한 자세한 내용은 KB0821436 단원을 참조하십시오.

MID Server를 업그레이드해야 하는 시기

인스턴스 버전과 버전이 다른 모든 MID 서버를 업그레이드해야 합니다. 다음 두 시스템 속성이 모든 MID Server의 버전을 제어합니다.

  • mid.buildstamp: 빌드 날짜를 기준으로 식별자로 MID 서버 버전을 식별합니다. 이 속성은 mm-dd-yyyy-hhmm 형식을 사용합니다. MID 서버는 매시간 버전 정보를 확인합니다. 재정의 버전이 구성되지 않은 경우 MID 서버는 사용할 버전에 대한 mid.buildstamp 속성을 확인합니다. 이 속성은 인스턴스를 다시 시작하거나 업그레이드할 때 기본 버전(인스턴스 버전과 일치하는 버전)으로 재설정되므로, 이때 사용자 변경 내용이 손실됩니다. 릴리스 이름과 패치 정보가 날짜 및 시간 형식에 추가됩니다.
    경고: 이 속성은 기본적으로 표시되지 않으므로 구성해서는 안 됩니다.
  • mid.version.override: 사용자 환경에 있는 모든 MID Server의 현재 버전에 대한 재정의 조건을 설정합니다. 이 작업은 MID Server를 단일 버전에 고정하고 자동 업그레이드 기능을 비활성화합니다. 이 속성은 기본 시스템에 표시되지 않으며 설정 시 시스템 속성 [sys_properties] 테이블에 추가해야 합니다. 자세한 내용은 시스템 속성 추가를 참조하십시오.

MID Server는 매시간 버전을 확인할 때 mid.version.override 속성을 먼저 확인합니다. 이 속성이 비어 있으면 MID Server는 mid.buildstamp 속성에서 버전 정보를 가져옵니다. 재정의 버전이 구성된 경우 MID Server는 이 값을 사용하고 mid.buildstamp 속성의 버전 정보를 무시합니다. 이 재정의 값은 인스턴스가 다시 시작되고 MID Server로 전달될 때 유지됩니다. 업그레이드 중에 mid.version.override 속성의 값이 지워져 MID 서버가 mid.buildstamp 속성의 버전으로 재설정됩니다.

mid.version.override 외에도 MID 서버를 특정 버전에 고정하는 구성 매개변수 mid.pinned.version을 사용하여 MID 서버 버전을 제어할 수도 있습니다. MID 서버를 고정하려면 mid.pinned.version 매개변수를 각 MID 서버의 config.xml 파일에 있는 해당 버전의 이름으로 설정합니다. <version>-mm-dd-yyyy 형식을 사용합니다. 이 설정은 고정된 MID 서버 버전에 대한 속성 설정을 무효화합니다. 지침은 MID 서버 매개변수 추가를 참조하십시오. 이 매개변수에 설정된 값은 업그레이드의 영향을 받지 않습니다.

경고: mid.version.override 및 mid.pinned.version은 사용하지 않는 것이 좋습니다. MID 서버 및 인스턴스의 버전이 다르면 MID 서버에서 중단 문제가 발생할 수 있습니다.

업그레이드 방법

자동
자동 업그레이드는 인스턴스 또는 MID 서버 자체에 의해 트리거될 수 있습니다. 이 기능은 기본적으로 사용할 수 있습니다. 자동 업그레이드가 발생합니다.
  • 인스턴스가 업그레이드되고 해당 버전의 MID 서버가 현재 MID 서버의 버전과 다른 경우 인스턴스가 연결된 MID Server에 autoUpgrade시스템 명령을 전송합니다.
  • MID 서버는 매시간 인스턴스를 확인하여 업그레이드에 사용할 수 있는 다른 버전이 있는지 확인합니다. 이 기간은 수정할 수 없습니다.
수동
MID 서버 기록에서 관련 링크를 클릭하여 업그레이드를 수동으로 시작합니다. 다음 시간별 자동 업데이트까지 기다리지 않으려는 경우 또는 업그레이드에 실패하여 업그레이드를 강제로 수행하려는 경우 이 방법을 사용합니다. 지침은 수동으로 MID 서버 업그레이드를 참조하십시오.

업그레이드 프로세스

  1. 업그레이드 전 확인:실제 MID 서버 업그레이드 프로세스를 시작하기 전에 MID 서버는 일련의 테스트를 실행하여 호스트 컴퓨터가 최소 요구사항을 충족하는지 확인합니다. 이 자동 테스트 중에 오류가 발생하면 문제가 해결될 때까지 업그레이드가 발생하지 않습니다. 업그레이드 전 테스트는 기본적으로 활성화되지만 시스템 속성을 추가하고 설정하여 비활성화할 수 있습니다. 자세한 내용은 MID 서버 업그레이드 전 확인 문서를 참조하십시오.
  2. 패키지 다운로드:MID 서버는 install.service-now.com 에서 업그레이드 패키지를 다운로드합니다. 이러한 패키지는 zip 형식이며 패키지/수신 폴더의 에이전트 폴더에 다운로드됩니다.
  3. 디지털 서명 검증

    모든 패키지를 다운로드한 후 MID 서버는 패키지의 디지털 서명을 확인합니다. 확인에 실패하면 예외가 발생합니다. 오류는 에이전트 로그와 MID 서버 문제 테이블에 기록됩니다.

    패키지를 수동으로 다운로드하고 교체하는 경우 서명을 수동으로 확인할 수 있습니다. 설치 또는 업그레이드 패키지의 서명을 수동으로 확인하려면 JDK에서 무료로 제공하는 jarsigner 도구를 사용합니다. 다음은 검증을 시작하는 jarsigner 명령입니다.Jarsigner -verify -verbose -certs -strict <zip-file>

    출력은 다음 예제와 유사해야 합니다.
    - Signed by "CN=ServiceNow Inc., O=ServiceNow Inc., L=Santa Clara, ST=California, C=US"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 2048-bit key
Timestamped by "CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US" on Tue Nov 05 19:55:37 UTC 2019
Timestamp digest algorithm: SHA-256
Timestamp signature algorithm: SHA256withRSA, 2048-bit key
 
jar verified.
 
The signer certificate will expire on 2021-08-09.
The timestamp will expire on 2029-03-22.
  4. Zip 파일 추출 중:필요한 모든 패키지를 다운로드한 후 MID 서버는 zip 파일을 추출합니다.
    • Rome 이전: zip 파일은 운영 체제에서 정의한 임시 폴더 아래의 폴더에 압축이 풀립니다. 폴더 이름은 임의로 생성된 번호입니다. 운영 체제 임시 폴더는 시스템 속성 java.io.tmpdir에 의해 지정됩니다. UNIX 호스트에서 이 등록 정보의 값은 일반적으로 /tmp 또는 /var/tmp입니다.
    • Rome 이후부터: MID 서버는 MID 서버 업그레이드 중에 운영 체제 정의 임시 폴더를 사용하지 않습니다. zip 파일은 에이전트 폴더 아래의 work/upgrade_temp 폴더에 있는 폴더에 압축이 풀립니다. 폴더 이름 형식은 임의로 생성된 숫자입니다. 이전 동작으로 전환하고 운영 체제에서 정의한 임시 폴더를 사용하려면 MID 서버의 config.xml 파일에 mid.upgrade.use_os_temp_folder추가하고 이를 true로 설정할 수 있습니다. 모든 MID 서버에 대한 동작을 전환하려면 MID 서버 필드를 공백으로 하여 MID 서버 속성 [ecc_agent_property]에 추가할 수 있습니다.
    주: KB0747569 사용하여java.io.tmpdir을 변경하고 Rome에서 향후 업그레이드할 수 있도록 유지하려면 Rome으로 업그레이드한 후 mid.upgrade.use_os_temp_foldertrue로 설정합니다. mid.upgrade.use_os_temp_folder true로 설정되지 않은 경우 MID 서버 업그레이드 중에 java.io.tmpdir이 적용되지 않고 agent\work\upgrade_temp 아래 폴더가 사용됩니다.
  5. 이전 패키지를 업그레이드된 패키지로 교체합니다.업그레이드 패키지를 다운로드하고 압축을 푼 후 MID 서버는 이전 파일을 새 파일로 바꾸고 새 버전으로 시작합니다. 패키지를 바꾸기 위해 MID 서버는 "ServiceNow AI Platform" 배포 업그레이드라는 프로세스를 시작하고 종료합니다. ServiceNow AI Platform 배포 업그레이드는 MID 서버가 제대로 종료될 때까지 기다린 다음 다음과 같이 필요한 파일을 대체합니다.
    • 로마 전:이 프로세스는 bin, lib 및 jre 폴더의 모든 파일과 폴더를 삭제하고 새 파일을 해당 폴더에 복사합니다.
    • 로마에서 이후: 이 프로세스는 파일의 새 버전이 이전 버전과 다른 경우에만 bin, lib 및 jre의 파일을 대체합니다. ServiceNow 플랫폼 배포 업그레이드 는 업그레이드 파일을 치료하지 않으며 변경되지 않은 파일은 유지됩니다.
    MID 서버 업그레이드의 일부로 서비스 재설치가 필요한 경우 ServiceNow 플랫폼 배포 업그레이드는 MID 서버를 시작하기 전에 서비스를 다시 설치합니다. 자세한 내용은 KB0821436 참조하십시오.
    주:

    이 단계에서 MID 서버 업그레이드가 실패하면 MID 서버는 작동 중지 상태를 유지합니다. 일부 바이러스 백신은 이 단계에서 파일 교체를 차단합니다. 자세한 내용은 KB0870329 참조하십시오.

  6. MID 서버를 시작합니다.필요한 모든 파일을 새 버전으로 바꾼 후 배포 업그레이드는 ServiceNow AI Platform MID 서버를 시작합니다. MID Server가 새 버전을 사용하면 업그레이드 파일을 추출하는 데 사용되는 모든 임시 폴더가 정리됩니다.

업그레이드 로그 메시지

MID 서버 로그 메시지는 다음 로그 파일에서 사용할 수 있습니다.

  • 업그레이드 전 검사 로그 메시지는 agent/logs 폴더 아래의 agent.log 파일에서 사용할 수 있습니다. 업그레이드 전 확인 테스트 수행 중이라는 메시지가 표시됩니다. 업그레이드 전 확인이 시작되었음을 나타냅니다. 필수 테스트를 모두 통과하면 업그레이드 전 확인 테스트 성공 메시지가 표시됩니다. 업그레이드 프로세스를 계속 진행합니다. 업그레이드 전 확인의 끝을 나타냅니다.

  • 누락된 파일을 다운로드하기 위한 로그 메시지도 agent.log에서 사용할 수 있습니다. 모든 패키지 다운로드는 PACKAGEINFO 메시지에서 PACKAGENAME.ZIP 패키지 다운로드 https://install.service-now.com/ 시작합니다. 다운로드 진행률과 다운로드한 파일의 크기는 로그에서 모니터링됩니다. 모든 패키지를 다운로드한 후 PACKAGEINFO에서 패키지가 성공적으로 다운로드 https://install.service-now.com/ 다운로드가 성공했음을 나타냅니다.

  • zip 파일 추출은 agent.log에서 사용할 수 있는 마지막 단계입니다. MID 서버 업그레이드 중 메시지는 이 단계의 시작을 나타내고 모든 패키지 추출에 대해 EXTRACT_TMP_FOLDER 패키지 추출 중 PACKAGE.ZIP 메시지가 표시됩니다. 필요한 모든 zip 파일의 압축이 풀리면 MID Server가 ServiceNow AI Platform 배포 업그레이드 프로세스를 시작하고 MID Server 중지 중이라는 메시지가 표시됩니다. 부트스트랩 업그레이드 는 MID 서버가 다운되기 전에 이 단계의 끝을 보여줍니다.
ServiceNow AI Platform 배포 업그레이드 로그에는 프로세스 시작 및 MID 서버 업그레이드 중 파일 교체에 대한 로그 메시지가 포함됩니다. 업그레이드 로그 메시지는 UPGRADE MAIN LOGIN START*********** 및 UPGRADE MAIN LOGIN END*********** 메시지 사이에 배치됩니다. ServiceNow AI Platform 배포 업그레이드 로그 메시지는 다음 로그 파일에서 찾을 수 있습니다.
  • temp extract 폴더 아래의 glide-dist-upgrade.log 파일에 있습니다. 이 파일은 임시 압축 풀기 폴더의 upgrade-wrapper/logs 폴더에서 사용할 수 있습니다. 이 로그 파일에는 프로세스 로그 메시지와 업그레이드 로그 메시지가 포함됩니다.
  • agent\logs 폴더의 dist-upgrade.log 파일에 있습니다. 이 파일에는 로그 메시지의 업그레이드 부분만 포함됩니다. 프로세스 시작에 문제가 있는 경우 glide-dist-upgrade.log 확인해야 합니다 .
  • agent\logs 폴더 아래의 wrapper.log에서. 파일을 교체한 후 ServiceNow AI Platform 배포 업그레이드는 wrapper.log 파일에 glide-dist-upgrade.log 추가합니다.

upgrade-wrapper-override.conf로 래퍼 구성 업데이트

glide-dist-upgrade에 대한 래퍼 구성은 upgrade-wrapper-override.conf 파일을 사용하여 업데이트할 수 있습니다. agent/conf 폴더에 upgrade-wrapper-override.conf 라는 파일을 생성합니다. upgrade-wrapper-override.conf의 모든 구성은 업그레이드 프로세스 중에 사용됩니다.

upgrade-wrapper-override.conf를 사용하여 구성을 수정하면 dist-upgrade 래퍼 수준에서 디버그 로그를 활성화할 수 있으며 변경 사항을 테스트할 수 있습니다.

예를 들어, 기본 제한시간은 특정 JVM 레벨 명령에 대해 충분히 길지 않을 수 있습니다. dist-upgrade 래퍼 구성에 대한 upgrade-wrapper-override.conf 를 사용하여 시간 제한을 늘릴 수 있습니다.

MID 서버 상태

업그레이드 중
업그레이드가 실행되는 동안 MID 서버 상태가 업그레이드 중으로 변경됩니다. 업그레이드 중 상태는 일시 중지됨 상태와 비슷합니다. 이렇게 하면 업그레이드 중에 인스턴스의 새 버전과 MID 서버의 이전 버전 간에 발생할 수 있는 잘못된 통신을 방지할 수 있습니다. 업그레이드 중 상태에서는 MID 서버를 다시 시작하거나 다시 시작할 수 없습니다. 그러나 MID 서버가 일시 중지됨 상태일 때 수행할 수 있는 것과 동일한 작업을 수행할 수 있습니다.
주: Istanbul 인스턴스를 사용 중이지만 Istanbul 이전 MID Server를 Istanbul로 업그레이드하는 경우에는 이러한 업그레이드 상태를 사용할 수 없습니다. 이미 이스탄불에 있는 MID 서버에서만 사용할 수 있습니다.
업그레이드 실패
업그레이드 전 확인 단계 또는 패키지 다운로드/압축 풀기 단계에서 업그레이드가 실패한 경우 실패한 업그레이드는 업그레이드하는 버전에 따라 다르게 처리됩니다.
  • 다른 주요 릴리스로 업그레이드(예: Istanbul에서 다음 정식 릴리스로): 상태가 업그레이드 실패로 변경됩니다.
  • 릴리스 내 부 버전에서 업그레이드(예: Jakarta 패치 1에서 패치 2로): MID 서버는 현재 실행 중인 버전을 계속 사용합니다. MID Server가 이미 제대로 작동하고 있다고 가정하여 업그레이드를 수행하지 않고 결국 상태가 Up으로 변경됩니다.
  • 마지막 단계에서 업그레이드가 실패하여 이전 버전의 패키지를 새 버전의 패키지로 바꾸면 MID 서버가 작동 중지 상태로 유지됩니다.

MID 서버 업그레이드 이력

MID 서버 업그레이드 문제 해결에 MID 서버 업그레이드 이력 모듈을 사용합니다. 이 모듈에는 각 인스턴스 업그레이드의 기록이 포함되어 있습니다. 이러한 기록은 각 MID 서버의 업그레이드 프로세스에 대한 단계별 상태 정보를 제공합니다. 오류가 발생하면 단계에 기록되고 추가 세부 정보가 포함된 메시지가 동적으로 생성됩니다. 테이블 정리 작업은 상태에 관계 없이 30일 동안 탐지되지 않은 문제를 자동으로 삭제합니다. 자세한 내용은 MID 서버 업그레이드 이력을 참조하십시오.

JRE 업데이트 중 JRE 신뢰 저장소 인증서 마이그레이션

Quebec으로 업그레이드한 후 JRE 업데이트의 경우 MID 서버는 JRE 신뢰 저장소의 자체 서명된 기존 인증서를 새 JRE 버전의 신뢰 저장소로 마이그레이션합니다. 이러한 인증서를 마이그레이션할 때 해당 별칭 앞에 문자열 "snc_"이 추가됩니다.

인증서를 마이그레이션하려면 다음 조건을 충족해야 합니다.

  • X509 인증서
  • 인증서 표준 v3
  • 기본 제약 조건 확장을 아니오로 설정합니다(즉, CA에서 발급하지 않음).

MID 서버는 JRE 업그레이드가 발생할 시기를 식별하고 마이그레이션 프로세스를 시작합니다. 마이그레이션 전에 MID 서버는 장애 발생 시 대비책으로 원래 신뢰 저장소의 백업을 생성합니다. 오류가 발생하면 백업 신뢰 저장소를 수동으로 복원할 수 있습니다.