SQL Server 2019 빅 데이터 클러스터 플랫폼 릴리스 정보

적용 대상: SQL Server 2019(15.x)

중요

Microsoft SQL Server 2019 빅 데이터 클러스터 추가 기능이 사용 중지됩니다. SQL Server 2019 빅 데이터 클러스터에 대한 지원은 2025년 1월 14일에 종료됩니다. Software Assurance를 사용하는 SQL Server 2019의 모든 기존 사용자는 플랫폼에서 완전히 지원되며, 소프트웨어는 지원 종료 시점까지 SQL Server 누적 업데이트를 통해 계속 유지 관리됩니다. 자세한 내용은 공지 블로그 게시물Microsoft SQL Server 플랫폼의 빅 데이터 옵션을 참조하세요.

다음 릴리스 정보는 SQL Server 2019 빅 데이터 클러스터에 적용됩니다. 이 문서는 CU 변경 내용을 설명하는 각 릴리스에 대한 섹션으로 구분됩니다. 이 문서에는 SQL Server 2019 빅 데이터 클러스터 최신 릴리스의 알려진 문제가 나와 있습니다.

테스트된 구성

SQL Server 2019 빅 데이터 클러스터는 Kubernetes에서 오케스트레이션되는 완전히 컨테이너화된 솔루션입니다. SQL Server 2019(15.x) CU12부터 각 SQL Server 빅 데이터 클러스터 릴리스는 고정 구성 요소 구성에 대해 테스트됩니다. 구성은 각 릴리스에서 평가되고 Kubernetes가 계속 발전함에 따라 에코시스템에 맞춰 조정됩니다.

중요

Kubernetes는 속도가 빠른 에코시스템입니다. 보안을 유지하고 SQL Server 빅 데이터 클러스터 대해 테스트된 구성을 사용하려면 플랫폼을 업데이트된 상태로 유지하는 것이 중요합니다.

경고

2019년 SQL Server(15.x) 누적 업데이트 15에서는 업그레이드 순서가 중요합니다. Kubernetes 클러스터를 버전 1.21로 업그레이드하기 전에 빅 데이터 클러스터를 CU15로 업그레이드하세요. BDC가 CU14 또는 CU15로 업그레이드되기 전에 Kubernetes 클러스터를 버전 1.21로 업그레이드하면 클러스터가 오류 상태로 전환되고 BDC 업그레이드에 실패합니다. 이 경우 Kubernetes 버전 1.20으로 되돌리면 문제가 해결됩니다.

다음 표에는 SQL Server 2019 빅 데이터 클러스터의 릴리스별로 테스트된 구성 매트릭스가 제공됩니다.

해제 컨테이너 OS Kubernetes API 런타임 데이터 스토리지 로그 스토리지
CU18 Ubuntu 20.04 LTS 1.23.1 containerd 1.4.6
CRI-O 1.20.4
블록 전용 블록 전용
CU17 Ubuntu 20.04 LTS 1.23.1 containerd 1.4.6
CRI-O 1.20.4
블록 전용 블록 전용
CU16 GDR Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
블록 전용 블록 전용
CU16 Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
블록 전용 블록 전용
CU15 Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
블록 전용 블록 전용
CU14 Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
블록 전용 블록 전용
CU13 Ubuntu 20.04 LTS 1.20 containerd 1.4.6
CRI-O 1.20.0
블록 전용 블록 전용
CU12 Ubuntu 20.04 LTS 1.20 containerd 1.4.3
docker 20.10.2
CRI-O 1.20.0
블록 전용 블록 전용

제한 사항:

  • SQL Server 2019 빅 데이터 클러스터는 워크로드로 지원됩니다. Microsoft는 SQL Server 2019 빅 데이터 클러스터에 의해서만 설치되고 구성된 컨테이너의 소프트웨어 구성 요소를 지원합니다. Kubernetes 자체, 그리고 SQL Server 2019 빅 데이터 클러스터 동작에 영향을 줄 수 있는 기타 컨테이너는 지원 팀에서 지원하지 않습니다. Kubernetes 지원에 대해서는 인증된 Kubernetes 배포 공급자에게 문의하세요.
  • SQL Server 2019 빅 데이터 클러스터의 경우 모든 지속형 볼륨에 블록 스토리지가 필요합니다. 빅 데이터 클러스터에서 만들고 사용하는 지속형 볼륨을 기반으로 하는 관리 작업은 PV(영구 볼륨)를 확장하는 작업처럼 스토리지 공급자를 사용하는 기능입니다. 특정 CSI 스토리지 공급자 설명서 또는 파트너 참조 아키텍처 및 백서를 참조하세요.
  • SQL Server 2019 빅 데이터 클러스터에 포함된 오픈 소스 구성 요소는 특정 릴리스에서 수정되며 업데이트하거나 수정해서는 안 됩니다.
  • 컨테이너 이미지는 “있는 그대로” 제공됩니다. Kubernetes의 구성 기능은 지원되지 않습니다. SQL Server 2019 빅 데이터 클러스터 릴리스에서 컨테이너 이미지 세트를 변경하거나 컨테이너를 사용자 지정할 수 없습니다.

SQL Server 빅 데이터 클러스터에 대한 참조 아키텍처 및 백서는 다음 페이지에서 찾을 수 있습니다.

릴리스 기록

다음 표에는 SQL Server 2019 빅 데이터 클러스터의 릴리스 기록이 나와 있습니다. 자세한 정보는 SQL Server 2019 빅 데이터 클러스터 누적 업데이트 기록을 참조하세요.

릴리스 1 SQL Server 2019 빅 데이터 클러스터 버전 Azure Data CLI(azdata) 버전 2 릴리스 날짜
CU18 15.0.4261.1 20.3.12 2022년 9월 28일
CU17 15.0.4249.2 20.3.12 2022년 8월 11일
CU16 GDR KB 5014356 15.0.4236.7 20.3.12 2022년 6월 14일
CU16 15.0.4223.1 20.3.11 2022년 5월 2일
CU15 15.0.4198.2 20.3.10 2022년 1월 27일
CU14 15.0.4188.2 20.3.9 2021년 11월 22일
CU13 15.0.4178.15 20.3.8 2021년 9월 9일
CU12 15.0.4153.13 20.3.7 2021년 8월 4일
CU11 15.0.4138.2 20.3.5 2021년 6월 10일
CU10 15.0.4123.1 20.3.2 2021년 4월 6일
CU9 15.0.4102.2 20.3.0 2021년 2월 11일
CU8-GDR 15.0.4083.2 20.2.6 2021년 1월 12일
CU8 15.0.4073.23 20.2.2 2020년 10월 19일
CU6 15.0.4053.23 20.0.1 2020년 8월 4일
CU5 15.0.4043.16 20.0.0 2020년 6월 22일
CU4 15.0.4033.1 15.0.4033 2020년 3월 31일
CU3 15.0.4023.6 15.0.4023 2020년 3월 12일
CU2 15.0.4013.40 15.0.4013 2020년 2월 13일
CU1 15.0.4003.23 15.0.4003 2020년 1월 7일
GDR1 15.0.2070.34 15.0.2070 2019년 11월 4일

1 CU7은 SQL Server 2019 빅 데이터 클러스터에 사용할 수 없습니다.

2 Azure Data CLI(azdata) 버전은 CU 릴리스 시점의 도구 버전을 반영합니다. azdata는 서버 릴리스와 별개로 릴리스할 수도 있으므로 최신 패키지를 설치하면 최신 버전을 가져올 수 있습니다. 최신 버전은 이전에 릴리스된 CU와 호환됩니다.

업데이트 설치 방법

업데이트를 설치하려면 SQL Server 빅 데이터 클러스터를 업그레이드하는 방법을 참조하세요.

알려진 문제

임의 오류가 있는 azdata를 사용하는 대용량 파일의 HDFS 복사본

  • 영향을 받는 릴리스: CU14

  • 문제 및 고객 효과: HDFS 경로 간의 azdata bdc cp 명령에 대해 임의 오류가 발생하는 버그였습니다. 이 버그는 더 큰 파일 복사본에 더 자주 영향을 줍니다.

  • 해결 방법: 누적 업데이트 15(CU15)로 업데이트합니다.

Log4j 보안

  • 영향을 받는 릴리스: 없음

  • 문제 및 고객 효과: SQL Server 2019 빅 데이터 클러스터 코드베이스를 철저히 평가한 후 12월에 보고된 log4j 취약성과 관련된 위험이 확인되지 않았습니다. CU15에는 빅 데이터 클러스터 컨테이너의 정적 코드 분석에 의해 이미지 검사 경고가 트리거되지 않도록 컨트롤 플레인의 ElasticSearch 인스턴스에 대한 log4j(2.17) 업데이트된 버전이 포함되어 있습니다.

  • 해결 방법: 항상 빅 데이터 클러스터를 최신 릴리스로 업데이트합니다.

CU8 및 이전 릴리스에서 CU9 이후 릴리스로 클러스터를 업그레이드할 수 없음

  • 영향을 받는 릴리스: CU8 및 이전 릴리스

  • 문제 및 고객에게 미치는 영향: CU8 또는 이전 릴리스의 클러스터를 CU9 이후 릴리스로 직접 업그레이드하는 경우 모니터링 단계에서 업그레이드가 실패합니다.

  • 해결 방법: 먼저 CU9로 업그레이드합니다. 그런 다음, CU9에서 최신 릴리스로 업그레이드합니다.

Kubernetes API 버전 1.21 이상을 사용하는 Kubernetes 플랫폼

  • 영향을 받는 릴리스: 모든 릴리스

  • 이슈 및 고객에게 미치는 영향: Kubernetes API 1.21 또는 상위 버전은 SQL Server 빅 데이터 클러스터 CU12의 테스트된 구성이 아닙니다.

SQL Server Machine Learning Services의 MicrosoftML 패키지

  • 영향을 받는 릴리스: CU10, CU11, CU12 및 CU13

  • 문제 및 고객에게 미치는 영향: SQL Server Machine Learning Services의 일부 MicrosoftML R/Python 패키지가 작동하지 않습니다. 모든 SQL Server 마스터 인스턴스에 영향을 줍니다.

SQL Server 2016 및 이전 버전의 원격 인스턴스에 연결할 수 없음

  • 영향을 받는 릴리스: CU10
  • 이슈 및 고객에게 미치는 영향: SQL Server 2019 빅 데이터 클러스터 CU10의 PolyBase를 사용하여, SHA1 알고리즘을 사용하여 만든 채널 암호화를 위해 인증서를 사용하는 기존 SQL Server 인스턴스에 연결하는 경우, 다음과 같은 오류가 발생할 수 있습니다.

Msg 105082, Level 16, State 1, Line 1 105082;Generic ODBC error: [Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: An existing connection was forcibly closed by the remote host. Additional error <2>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection, SqlState: 08001, NativeError: 10054 Additional error <3>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server] Invalid connection string attribute, SqlState: 01S00, NativeError: 0 .

  • 해결 방법: 이전 기본 이미지 버전보다 Ubuntu 20.04의 보안 요구 사항이 더 엄격하기 때문에 SHA1 알고리즘을 사용하는 인증서의 경우 원격 연결이 허용되지 않습니다. SQL Server 릴리스 2005~2016의 기본 자체 서명된 인증서는 SHA1 알고리즘을 사용했습니다. 이 변경에 대한 자세한 내용은 SQL Server 2017의 자체 서명된 인증서에 적용된 변경 내용을 참조하세요. 원격 SQL Server 인스턴스에서, 최소 112비트 보안을 사용하는 알고리즘(예: SHA256)으로 만든 인증서를 사용하세요. 프로덕션 환경에서는 신뢰할 수 있는 인증서를 인증 기관에서 발급받는 것이 좋습니다. 테스트 목적으로 자체 서명된 인증서를 사용할 수도 있습니다. 자체 서명된 인증서를 만들려면 PowerShell Cmdlet New-SelfSignedCertificate 또는 certreq 명령을 참조하세요. 원격 SQL Server 인스턴스에 새 인증서를 설치하는 방법은 Enable encrypted connections to the Database Engine(데이터베이스 엔진에 대한 암호화된 연결 사용 설정)을 참조하세요.

롤백 시 ElasticSearch에 수집된 로그의 일부가 손실됨

  • 영향을 받는 릴리스: CU9으로 업그레이드하지 못하여 롤백이 발생하거나 사용자가 이전 릴리스로 다운그레이드하는 경우 기존 클러스터에 영향을 줍니다.

  • 이슈 및 고객에게 미치는 영향: ElasticSearch에 사용되는 소프트웨어 버전이 CU9으로 업그레이드되었지만 새 버전이 이전 로그 형식/메타데이터와 호환되지 않습니다. ElasticSearch 구성 요소를 성공적으로 업그레이드하더라도 이후 롤백이 트리거되면 ElasticSearch 업그레이드와 롤백 사이에 수집된 로그가 영구적으로 손실됩니다. 이전 버전의 SQL Server 2019 빅 데이터 클러스터로 다운그레이드를 실행하는 경우(권장하지 않음) ElasticSearch에 저장된 로그가 손실됩니다. 다시 CU9로 업그레이드하면 데이터가 복원됩니다.

  • 해결 방법: 필요한 경우 azdata bdc debug copy-logs 명령을 통해 수집된 로그를 사용하여 문제를 해결할 수 있습니다.

누락된 Pod 및 컨테이너 메트릭

  • 영향을 받는 릴리스: CU9으로 업그레이드 시 기존 클러스터와 새 클러스터에 영향

  • 문제 및 고객에게 미치는 영향: CU9에서 모니터링 구성 요소에 사용되는 Telegraf 버전을 업그레이드할 경우 클러스터를 CU9 릴리스로 업그레이드하면 Pod 및 컨테이너 메트릭이 수집되지 않습니다. 소프트웨어 업그레이드의 결과로 Telegraf에 사용되는 클러스터 역할의 정의에 추가 리소스가 필요하기 때문입니다. 클러스터를 배포하거나 업그레이드를 수행하는 사용자에게 충분한 권한이 없는 경우에는 경고와 함께 배포/업그레이드가 진행되고 작업이 성공하지만 Pod 및 노드 메트릭은 수집되지 않습니다.

  • 해결 방법: 배포/업그레이드 전에 또는 후에 관리자에게 역할 및 해당 서비스 계정을 만들거나 업그레이드해 달라고 요청하면 됩니다. 그러면 빅 데이터 클러스터가 이 역할 및 서비스 계정을 사용합니다. 이 문서에서는 필요한 아티팩트를 만드는 방법을 설명합니다.

azdata bdc copy-logs를 실행해도 로그가 복사되지 않음

  • 영향을 받는 릴리스: Azure Data CLI(azdata) 버전 20.0.0

  • 이슈 및 고객에게 미치는 영향: copy-logs 명령의 구현은 명령이 실행되는 클라이언트 머신에 kubectl 클라이언트 도구 버전 1.15 이상이 설치되어 있다고 가정합니다. kubectl 버전 1.14를 사용하는 경우 azdata bdc debug copy-logs 명령이 실패 없이 완료되지만 로그는 복사되지 않습니다. --debug 플래그를 사용하여 실행하는 경우 출력에 source '.' is invalid 오류가 표시됩니다.

  • 해결 방법: 동일한 클라이언트 머신에 kubectl 버전 1.15 이상 도구를 설치하고 azdata bdc copy-logs 명령을 다시 실행합니다. kubectl을 설치하는 방법에 대한 지침은 여기를 참조하세요.

SQL Server 마스터 인스턴스에서 MSDTC 기능을 사용하도록 설정할 수 없습니다.

  • 영향을 받는 릴리스: 릴리스에 관계없이 모든 빅 데이터 클러스터 배포 구성입니다.

  • 이슈 및 고객에게 미치는 영향: 빅 데이터 클러스터 내에 SQL Server 마스터 인스턴스로 배포된 SQL Server에서는 MSDTC 기능을 활성화할 수 없습니다. 이 문제를 해결하는 방법은 없습니다.

HA SQL Server 데이터베이스 암호화 키 암호기 회전

  • 영향을 받는 릴리스: CU8까지 모든 버전입니다. CU9에서 문제가 해결되었습니다.

  • 이슈 및 고객에게 미치는 영향: HA를 사용하여 배포된 SQL Server에서는 암호화된 데이터베이스에 대한 인증서 회전이 실패합니다. 마스터 풀에서 다음 명령을 실행하면 오류 메시지가 표시됩니다.

    ALTER DATABASE ENCRYPTION KEY
    ENCRYPTION BY SERVER
    CERTIFICATE <NewCertificateName>
    

    영향은 전혀 없으며 명령이 실패하고 대상 데이터베이스 암호화는 이전 인증서를 사용하여 유지됩니다.

CU8에서 HDFS 암호화 영역 지원 사용

  • 영향을 받는 릴리스: 특히 CU6 이하에서 CU8로 업그레이드하는 경우 이 시나리오가 나타납니다. CU8 이상의 새 배포에서 또는 CU9로 직접 업그레이드하는 경우에는 이 문제가 발생하지 않습니다. CU10 또는 상위 릴리스는 영향을 받지 않습니다.

  • 이슈 및 고객에게 미치는 영향: HDFS 암호화 영역 지원은 이 시나리오에서 기본적으로 사용할 수 없으며 구성 가이드에 제공된 단계에 따라 구성해야 합니다.

누적 업데이트를 적용하기 전의 빈 Livy 작업

  • 영향을 받는 릴리스: CU6까지의 모든 버전. CU8에서 문제가 해결되었습니다.

  • 이슈 및 고객에게 미치는 영향: 업그레이드하는 동안 sparkhead가 404 오류를 반환합니다.

  • 해결 방법: 빅 데이터 클러스터를 업그레이드하기 전에 활성 Livy 세션 또는 일괄 처리 작업이 없는지 확인합니다. 이 문제를 방지하려면 지원되는 릴리스에서 업그레이드의 지침을 따르세요.

    업그레이드 프로세스 중에 Livy에서 404 오류를 반환하는 경우 두 sparkhead 노드에서 모두 Livy 서버를 다시 시작합니다. 예를 들어:

    kubectl -n <clustername> exec -it sparkhead-0/sparkhead-1 -c hadoop-livy-sparkhistory -- exec supervisorctl restart livy
    

빅 데이터 클러스터 생성 서비스 계정의 암호 만료

  • 영향을 받는 릴리스: 릴리스에 관계없이 Active Directory 통합을 사용한 모든 빅 데이터 클러스터 배포

  • 이슈 및 고객에게 미치는 영향: 빅 데이터 클러스터를 배포하는 동안 워크플로에서 서비스 계정 세트를 생성합니다. 도메인 컨트롤러에 설정된 암호 만료 정책에 따라 이 계정의 암호는 만료될 수 있습니다(기본값은 42일). 이 때 빅 데이터 클러스터의 모든 계정에 대한 자격 증명을 회전하는 메커니즘이 없으므로 만료 기간이 경과하면 클러스터가 작동하지 않게 됩니다.

  • 해결 방법: 도메인 컨트롤러에서 빅 데이터 클러스터의 서비스 계정 만료 정책을 “암호 사용 기간 제한 없음”으로 업데이트합니다. 이러한 계정의 전체 목록은 자동 생성 Active Directory 개체를 참조하세요. 이 작업은 만료 이전 또는 이후에 수행할 수 있습니다. 후자의 경우 만료된 암호를 Active Directory가 다시 활성화합니다.

게이트웨이 엔드포인트를 통해 서비스에 액세스하기 위한 자격 증명

  • 영향을 받는 릴리스: CU5부터 새 클러스터가 배포됩니다.

  • 이슈 및 고객에게 미치는 영향: SQL Server 빅 데이터 클러스터 CU5를 사용하여 배포된 새로운 빅 데이터 클러스터의 경우 게이트웨이 사용자 이름은 루트가 아닙니다. 게이트웨이 엔드포인트에 연결하는 데 사용된 애플리케이션에서 잘못된 자격 증명을 사용하는 경우 인증 오류가 표시됩니다. 이런 변경은 루트가 아닌 사용자로 빅 데이터 클러스터 내에서 애플리케이션을 실행한 결과입니다(SQL Server 빅 데이터 클러스터 CU5 릴리스부터 새로운 기본 동작, CU5를 사용하여 새 빅 데이터 클러스터를 배포할 때 게이트웨이 엔드포인트의 사용자 이름은 AZDATA_USERNAME 환경 변수를 통해 전달된 값을 기반으로 함). 이때 사용자 이름은 컨트롤러 및 SQL Server 엔드포인트에 사용되는 것과 동일합니다. 이런 현상은 새 배포에만 영향을 미치며, 이전 릴리스를 사용하여 배포된 기존 빅 데이터 클러스터는 계속 루트를 사용합니다. Active Directory 인증을 사용하도록 클러스터를 배포하는 경우 자격 증명에는 영향이 없습니다.

  • 해결 방법: Azure Data Studio는 게이트웨이 연결에 대해 자격 증명 변경을 투명하게 처리하여 ObjectExplorer에서 HDFS 검색 환경을 사용하도록 설정합니다. 이 사용 사례를 처리하는 데 필요한 변경 내용이 포함된 최신 Azure Data Studio 릴리스를 설치해야 합니다. 게이트웨이를 통해 서비스에 액세스하기 위해 자격 증명을 제공해야 하는 다른 시나리오(예: Azure Data CLI(azdata)를 사용하여 로그인, Spark용 웹 대시보드 액세스)의 경우 올바른 자격 증명을 사용해야 합니다. CU5 이전에 배포된 기존 클러스터를 대상으로 하는 경우 클러스터를 CU5로 업그레이드한 후에도 계속 루트 사용자 이름을 사용하여 게이트웨이에 연결합니다. CU5 빌드를 사용하여 새 클러스터를 배포하는 경우 AZDATA_USERNAME 환경 변수에 해당하는 사용자 이름을 제공하여 로그인합니다.

Pod 및 노드 메트릭이 수집되지 않음

  • 영향을 받는 릴리스: CU5 이미지를 사용하는 새 클러스터 및 기존 클러스터

  • 이슈 및 고객에게 미치는 영향: telegraf에서 메트릭 Pod 및 호스트 노드 메트릭을 수집하는 데 사용한 API와 관련된 보안 수정의 결과, 고객은 메트릭이 수집되지 않는 것을 경험했을 수도 있습니다. 이런 현상은 (CU5로 업그레이드한 후) SQL Server 2019 빅 데이터 클러스터의 새 배포와 기존 배포 모두에서 일어날 수 있습니다. 수정 결과로, 이제 Telegraf에서 클러스터 수준의 역할 권한이 있는 서비스 계정을 요구합니다. 배포에서 필요한 서비스 계정 및 클러스터 역할을 만들려고 시도하지만 클러스터를 배포하거나 업그레이드를 수행하는 사용자에게 충분한 권한이 없는 경우에는 배포/업그레이드가 진행되고 경고가 나타나며 성공하지만 Pod 및 노드 메트릭은 수집되지 않습니다.

  • 해결 방법: 배포/업그레이드 전이나 후에 관리자에게 해당 역할 및 서비스 계정을 만들도록 요청하면 됩니다. 그러면 빅 데이터 클러스터가 이 역할 및 서비스 계정을 사용합니다. 이 문서에서는 필요한 아티팩트를 만드는 방법을 설명합니다.

azdata bdc copy-logs 명령 실패

  • 영향을 받는 릴리스: Azure Data CLI(azdata) 버전 20.0.0

  • 이슈 및 고객에게 미치는 영향: copy-logs 명령의 구현은 명령이 실행되는 클라이언트 머신에 kubectl 클라이언트 도구가 설치되어 있다고 가정합니다. oc 도구만 설치된 클라이언트에서 OpenShift에 설치된 빅 데이터 클러스터에 대해 명령을 실행하는 경우 An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified 오류가 발생합니다.

  • 해결 방법: 동일한 클라이언트 머신에 kubectl 도구를 설치하고 azdata bdc copy-logs 명령을 다시 실행합니다. kubectl을 설치하는 방법에 대한 지침은 여기를 참조하세요.

프라이빗 리포지토리를 사용하여 배포

  • 영향을 받는 릴리스: GDR1, CU1, CU2. CU3에서 문제가 해결되었습니다.

  • 이슈 및 고객에게 미치는 영향: 프라이빗 리포지토리에서 업그레이드하는 경우 특정 요구 사항이 있습니다.

  • 해결 방법: 프라이빗 리포지토리를 사용하여 빅 데이터 클러스터를 배포하거나 업그레이드하기 위해 이미지를 미리 가져오는 경우 현재 빌드 이미지와 대상 빌드 이미지가 프라이빗 리포지토리에 있는지 확인합니다. 이렇게 하면 필요한 경우 성공적으로 롤백할 수 있습니다. 또한 원래 배포 이후 프라이빗 리포지토리의 자격 증명을 변경한 경우 업그레이드하기 전에 Kubernetes에서 해당 비밀을 업데이트합니다. Azure Data CLI(azdata)는 AZDATA_PASSWORDAZDATA_USERNAME 환경 변수를 통한 자격 증명 업데이트를 지원하지 않습니다. kubectl edit secrets를 사용하여 암호를 업데이트합니다.

현재 및 대상 빌드에 다른 리포지토리를 사용하여 업그레이드할 수 없습니다.

시간 초과로 인해 업그레이드가 실패할 수 있음

  • 영향을 받는 릴리스: GDR1, CU1, CU2. CU3에서 문제가 해결되었습니다.

  • 이슈 및 고객에게 미치는 영향: 시간 제한으로 인해 업그레이드가 실패할 수 있습니다.

    다음 코드는 오류가 어떻게 표시되는지 보여 줍니다.

    >azdata.EXE bdc upgrade --name <mssql-cluster>
    Upgrading cluster to version 15.0.4003
    
    NOTE: Cluster upgrade can take a significant amount of time depending on
    configuration, network speed, and the number of nodes in the cluster.
    
    Upgrading Control Plane.
    Control plane upgrade failed. Failed to upgrade controller.
    

    이 오류는 AKS(Azure Kubernetes Service)에서 SQL Server 2019 빅 데이터 클러스터를 업그레이드할 때 발생할 가능성이 높습니다.

  • 해결 방법: 업그레이드 시간 제한을 늘립니다.

    업그레이드에 대한 시간 제한을 늘리려면 업그레이드 구성 맵을 편집합니다. 업그레이드 구성 맵을 편집하려면 다음을 수행합니다.

    1. 다음 명령 실행:

      kubectl edit configmap controller-upgrade-configmap
      
    2. 다음 필드를 편집합니다.

      controllerUpgradeTimeoutInMinutes 컨트롤러 또는 컨트롤러 db의 업그레이드가 완료될 때까지 대기할 시간(분)을 지정합니다. 기본값은 5입니다. 20 이상으로 업데이트합니다.

      totalUpgradeTimeoutInMinutes: 컨트롤러와 컨트롤러 db 모두가 업그레이드(controller + controllerdb 업그레이드)를 완료하는 데 걸리는 시간을 합한 값을 지정합니다. 기본값은 10입니다. 40 이상으로 업데이트합니다.

      componentUpgradeTimeoutInMinutes : 업그레이드의 각 후속 단계를 완료해야 하는 기간을 지정합니다. 기본값은 30입니다. 45로 업데이트합니다.

    3. 저장한 후 종료합니다.

    다음 Python 스크립트는 시간 제한을 설정하는 또 다른 방법입니다.

    from kubernetes import client, config
    import json
    
    def set_upgrade_timeouts(namespace, controller_timeout=20, controller_total_timeout=40, component_timeout=45):
         """ Set the timeouts for upgrades
    
         The timeout settings are as follows
    
         controllerUpgradeTimeoutInMinutes: sets the max amount of time for the controller
             or controllerdb to finish upgrading
    
         totalUpgradeTimeoutInMinutes: sets the max amount of time to wait for both the
             controller and controllerdb to complete their upgrade
    
         componentUpgradeTimeoutInMinutes: sets the max amount of time allowed for
             subsequent phases of the upgrade to complete
         """
         config.load_kube_config()
    
         upgrade_config_map = client.CoreV1Api().read_namespaced_config_map("controller-upgrade-configmap", namespace)
    
         upgrade_config = json.loads(upgrade_config_map.data["controller-upgrade"])
    
         upgrade_config["controllerUpgradeTimeoutInMinutes"] = controller_timeout
    
         upgrade_config["totalUpgradeTimeoutInMinutes"] = controller_total_timeout
    
         upgrade_config["componentUpgradeTimeoutInMinutes"] = component_timeout
    
         upgrade_config_map.data["controller-upgrade"] = json.dumps(upgrade_config)
    
         client.CoreV1Api().patch_namespaced_config_map("controller-upgrade-configmap", namespace, upgrade_config_map)
    

ADS(Azure Data Studio) 또는 curl에서 Livy 작업 제출 시 500 오류가 발생하고 제출이 실패함

  • 이슈 및 고객에게 미치는 영향: HA 구성에서는 Spark 공유 리소스 sparkhead가 여러 복제본으로 구성되어 있습니다. 이 경우 ADS(Azure Data Studio) 또는 curl에서 Livy 작업을 제출할 때 제출에 실패할 수 있습니다. 확인하려면 거부된 연결의 sparkhead pod 결과로 curl해 보세요. 예를 들어, curl https://sparkhead-0:8998/이나 curl https://sparkhead-1:8998은 500 오류를 반환합니다.

    이 문제는 다음과 같은 경우에 발생합니다.

    • Zookeeper pod 또는 각 Zookeeper 인스턴스의 프로세스가 몇 차례 다시 시작된 경우
    • sparkhead pod과 Zookeeper pod 사이의 네트워크 연결이 불안정한 경우
  • 해결 방법: 두 Livy 서버를 모두 다시 시작합니다.

    kubectl -n <clustername> exec sparkhead-0 -c hadoop-livy-sparkhistory supervisorctl restart livy
    
    kubectl -n <clustername> exec sparkhead-1 -c hadoop-livy-sparkhistory supervisorctl restart livy
    

마스터 인스턴스가 가용성 그룹에 있을 때 메모리 최적화 테이블 만들기

  • 문제 및 고객에게 미치는 영향: 가용성 그룹 데이터베이스(수신기) 연결을 위해 노출된 기본 엔드포인트를 사용하여 메모리 최적화 테이블을 만들 수 없습니다.

  • 해결 방법: SQL Server 마스터 인스턴스가 가용성 그룹 구성일 때 메모리 최적화 테이블을 만들려면 SQL Server 인스턴스에 연결하고, 엔드포인트를 노출하고, SQL Server 데이터베이스에 연결한 다음, 새 연결로 만든 세션에서 메모리 최적화 테이블을 만듭니다.

Active Directory 인증 모드에서 외부 테이블에 삽입

  • 이슈 및 고객에게 미치는 영향: SQL Server 마스터 인스턴스가 Active Directory 인증 모드에 있을 때, 외부 테이블 중 적어도 하나 이상이 스토리지 풀에 있는 외부 테이블에서만 선택하여 다른 외부 테이블에 삽입하는 쿼리는 다음을 반환합니다.

Msg 7320, Level 16, State 102, Line 1 Cannot execute the query "Remote Query" against OLE DB provider "SQLNCLI11" for linked server "SQLNCLI11". Only domain logins can be used to query Kerberized storage pool.

  • 해결 방법: 다음 방법을 사용하여 쿼리를 수정합니다. 스토리지 풀 테이블을 로컬 테이블에 조인하거나 먼저 로컬 테이블에 삽입한 다음 이 로컬 테이블에서 읽어서 데이터 풀에 삽입합니다.

SQL Server 마스터 인스턴스에서 가용성 그룹의 일부인 데이터베이스에는 투명한 데이터 암호화 기능을 사용할 수 없음

  • 이슈 및 고객에게 미치는 영향: HA 구성에서는 암호화에 사용되는 마스터 키가 각 복제본마다 다르기 때문에 암호화가 사용된 데이터베이스는 장애 조치(failover) 후에 사용할 수 없습니다.

  • 해결 방법: 이 문제를 해결하는 방법은 없습니다. 수정될 때까지 이 구성에서 암호화를 사용하지 않는 것이 좋습니다.

다음 단계

SQL Server 2019 빅 데이터 클러스터에 대한 자세한 내용은 SQL Server 빅 데이터 클러스터 소개를 참조하세요.