다음을 통해 공유


빠른 시작 - Azure Managed Instance for Apache Cassandra를 사용하여 하이브리드 클러스터 구성

Azure Managed Instance for Apache Cassandra는 순수 오픈 소스 Apache Cassandra 클러스터를 위한 완전 관리형 서비스입니다. 또한 이 서비스를 사용하면 각 워크로드의 특정 요구 사항에 따라 최대한의 유연성과 제어를 위해 구성을 재정의할 수 있습니다.

이 빠른 시작에서는 Azure CLI 명령을 사용하여 하이브리드 클러스터를 구성하는 방법을 보여 줍니다. 온-프레미스 또는 자체 호스팅 환경에 기존 데이터 센터가 있는 경우 Apache Cassandra용 Azure Managed Instance를 사용하여 해당 클러스터에 다른 데이터 센터를 추가하고 유지 관리할 수 있습니다.

필수 구성 요소

  • 이 문서에는 Azure CLI 버전 2.30.0 이상이 필요합니다. Azure Cloud Shell을 사용하는 경우 최신 버전이 이미 설치되어 있습니다.
  • 자체 호스팅 또는 온-프레미스 환경에 연결된 Azure 가상 네트워크를 사용합니다. 온-프레미스 환경을 Azure에 연결하는 방법에 대한 자세한 내용은 Azure에 온-프레미스 네트워크 연결을 참조하세요.

하이브리드 클러스터 구성

  1. Azure Portal에 로그인하고 가상 네트워크 리소스로 이동합니다.

  2. 서브넷 탭을 선택하고 새 서브넷을 만듭니다. 서브넷 추가 양식의 필드에 대한 자세한 내용은 서브넷 추가를 참조하세요.

    가상 네트워크에 새 서브넷을 옵트인하고 추가하는 옵션을 보여 주는 스크린샷

    Apache Cassandra용 Azure Managed Instance를 배포하려면 인터넷에 액세스해야 합니다. 인터넷 액세스가 제한되는 환경에서는 배포가 실패합니다. Apache Cassandra용 Azure Managed Instance가 제대로 작동하는 데 필요한 다음과 같은 중요한 Azure 서비스에 대한 가상 네트워크 내의 액세스를 차단하지 않는지 확인합니다. IP 주소 및 포트 종속성 목록은 필수 아웃바운드 네트워크 규칙을 참조하세요.

    • Azure Storage
    • Azure Key Vault (애저 키 볼트)
    • Azure Virtual Machine Scale Sets (Azure 가상 머신 스케일 세트)
    • Azure Monitor (Azure 모니터)
    • Microsoft Entra ID (마이크로소프트 엔트라 ID)
    • 클라우드용 Microsoft Defender
  3. Azure CLI를 사용하여 Apache Cassandra용 Azure Managed Instance에 필요한 가상 네트워크 및 서브넷에 몇 가지 특별한 권한을 적용합니다. az role assignment create 명령 사용 <subscriptionID>, <resourceGroupName>, <vnetName>를 적절한 값으로 바꾸세요.

    az role assignment create \
      --assignee a232010e-820c-4083-83bb-3ace5fc29d0b \
      --role 4d97b98b-1d4f-4787-a291-c67834d212e7 \
      --scope /subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>
    

    이전 명령에서 assignee 값은 고정 서비스 주체 식별자이고, role 값은 역할 식별자입니다.

  4. 하이브리드 클러스터에 대한 리소스를 구성합니다. 클러스터가 이미 있으므로 클러스터 이름은 기존 클러스터의 이름을 식별하는 논리 리소스입니다. 다음 스크립트에서 정의 clusterName 할 때 기존 클러스터의 clusterNameOverride 이름과 변수를 사용합니다.

    또한 기존 데이터 센터의 시드 노드와 노드 간 암호화에 필요한 가십 인증서가 최소한 필요합니다. Azure Managed Instance for Apache Cassandra에는 데이터 센터 간 통신을 위해 노드 간 암호화가 필요합니다. 기존 클러스터에 노드 간 암호화가 구현되지 않은 경우 구현해야 합니다. 자세한 내용은 노드 간 암호화를 참조하세요. 인증서의 위치에 대한 경로를 제공합니다. 각 인증서는 PEM(개인 정보 보호 강화 메일) 형식이어야 합니다( 예: ) -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. 일반적으로 인증서를 구현하는 방법에는 두 가지가 있습니다.

    • 자체 서명된 인증서입니다. 각 노드에 대한 CA(인증 기관)가 없는 프라이빗 및 공용 인증서입니다. 이 경우 모든 공용 인증서가 필요합니다.
    • CA에서 서명한 인증서입니다. 자체 서명된 CA 또는 공용 CA에서 발급한 인증서입니다. 이 경우 루트 CA 인증서 및 모든 중간자(해당하는 경우)가 필요합니다. 자세한 내용은 프로덕션용 SSL(Secure Sockets Layer) 인증서 준비를 참조하세요.

    필요에 따라 클라이언트-노드 인증서 인증 또는 TLS(상호 전송 계층 보안)를 구현하려는 경우 하이브리드 클러스터를 만들 때와 동일한 형식으로 인증서를 제공합니다. 이 문서의 뒷부분에 있는 Azure CLI 샘플을 참조하세요. 인증서는 매개 변수에 --client-certificates 제공됩니다.

    이 방법은 Azure Managed Instance for Apache Cassandra 클러스터의 신뢰 저장소에 클라이언트 인증서를 업로드하고 적용합니다. 설정을 편집 cassandra.yaml 할 필요가 없습니다. 인증서가 적용된 후 클러스터는 클라이언트가 연결할 때 Cassandra가 인증서를 확인해야 합니다. 자세한 내용은 require_client_auth: true Cassandra client_encryption_options 참조하세요.

    이 코드에서 제공하는 변수의 delegatedManagementSubnetId 값은 이전 명령에서 제공한 값 --scope 과 동일합니다.

    resourceGroupName='MyResourceGroup'
    clusterName='cassandra-hybrid-cluster-legal-name'
    clusterNameOverride='cassandra-hybrid-cluster-illegal-name'
    location='eastus2'
    delegatedManagementSubnetId='/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>'
    
    # You can override the cluster name if the original name isn't legal for an Azure resource:
    # overrideClusterName='ClusterNameIllegalForAzureResource'
    # the default cassandra version will be v3.11
    
    az managed-cassandra cluster create \
      --cluster-name $clusterName \
      --resource-group $resourceGroupName \
      --location $location \
      --delegated-management-subnet-id $delegatedManagementSubnetId \
      --external-seed-nodes 10.52.221.2 10.52.221.3 10.52.221.4 \
      --external-gossip-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/gossipKeyStore.crt_signed
      # optional - add your existing datacenter's client-to-node certificates (if implemented):
      # --client-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/nodeKeyStore.crt_signed
    

    클러스터에 노드 간 및 클라이언트-노드 암호화가 이미 설정된 경우 기존 클라이언트 또는 가십 TLS/SSL 인증서가 유지되는 위치를 알아야 합니다. 확실하지 않은 경우 실행 keytool -list -keystore <keystore-path> -rfc -storepass <password> 하여 인증서를 인쇄합니다.

  5. 클러스터 리소스가 생성되면 다음 명령을 실행하여 클러스터 설정 세부 정보를 가져옵니다.

    resourceGroupName='MyResourceGroup'
    clusterName='cassandra-hybrid-cluster'
    
    az managed-cassandra cluster show \
       --cluster-name $clusterName \
       --resource-group $resourceGroupName \
    
  6. 이전 명령은 관리형 인스턴스 환경에 대한 정보를 반환합니다. 기존 데이터 센터의 노드에 대한 신뢰 저장소에 이를 설치할 수 있도록 가십 인증서가 필요합니다. 다음 스크린샷은 이전 명령의 출력과 인증서 형식을 보여 줍니다.

    클러스터에서 인증서 세부 정보를 가져오는 결과를 보여 주는 스크린샷

    이전 명령에서 반환된 인증서에는 텍스트로 표시되는 줄 바꿈이 포함됩니다. 예제는 \r\n입니다. 기존 트러스트 저장소로 가져오기 전에 각 인증서를 파일에 복사하고 서식을 지정합니다.

    스크린샷에 gossipCertificates 표시된 배열 값을 파일에 복사합니다. 다음 Bash 스크립트를 사용하여 인증서의 서식을 지정하고 각각에 대해 별도의 PEM 파일을 만듭니다. Bash 스크립트를 다운로드하려면 플랫폼에 대한 jq 다운로드 를 참조하세요.

    readarray -t cert_array < <(jq -c '.[]' gossipCertificates.txt)
    # iterate through the certs array, format each cert, write to a numbered file.
    num=0
    filename=""
    for item in "${cert_array[@]}"; do
    let num=num+1
    filename="cert$num.pem"
    cert=$(jq '.pem' <<< $item)
    echo -e $cert >> $filename
    sed -e 's/^"//' -e 's/"$//' -i $filename
    done
    
  7. 다음으로, 하이브리드 클러스터에 새 데이터 센터를 만듭니다. 변수 값을 클러스터 세부 정보로 바꿉다.

    resourceGroupName='MyResourceGroup'
    clusterName='cassandra-hybrid-cluster'
    dataCenterName='dc1'
    dataCenterLocation='eastus2'
    virtualMachineSKU='Standard_D8s_v4'
    noOfDisksPerNode=4
    
    az managed-cassandra datacenter create \
      --resource-group $resourceGroupName \
      --cluster-name $clusterName \
      --data-center-name $dataCenterName \
      --data-center-location $dataCenterLocation \
      --delegated-subnet-id $delegatedManagementSubnetId \
      --node-count 9
      --sku $virtualMachineSKU \
      --disk-capacity $noOfDisksPerNode \
      --availability-zone false
    

    다음의 사용 가능한 제품 계층에서 --sku의 값을 선택하십시오.

    • Standard_E8s_v4
    • Standard_E16s_v4
    • Standard_E20s_v4
    • Standard_E32s_v4
    • Standard_DS13_v2
    • Standard_DS14_v2
    • Standard_D8s_v4
    • Standard_D16s_v4
    • Standard_D32s_v4

    --availability-zone의 설정이 false로 되어 있습니다. 가용성 영역을 사용하도록 설정하려면 이 값을 true.로 설정합니다. 가용성 영역은 서비스의 가용성 SLA(서비스 수준 계약)를 증가합니다. 자세한 내용은 온라인 서비스에 대한 SLA를 참조하세요.

    가용성 영역은 모든 지역에서 지원되지 않습니다. 가용성 영역이 지원되지 않는 지역을 선택하면 배포가 실패합니다. 지원되는 지역은 Azure 지역 목록을 참조하세요.

    가용성 영역의 성공적인 배포에는 특정 지역의 모든 영역에서 컴퓨팅 리소스의 가용성이 적용됩니다. 선택한 제품 계층 또는 용량을 일부 영역에서 사용할 수 없는 경우 배포가 실패할 수 있습니다.

  8. 이제 새 데이터 센터가 생성되었으므로 명령을 실행 datacenter show 하여 세부 정보를 확인합니다.

    resourceGroupName='MyResourceGroup'
    clusterName='cassandra-hybrid-cluster'
    dataCenterName='dc1'
    
    az managed-cassandra datacenter show \
      --resource-group $resourceGroupName \
      --cluster-name $clusterName \
      --data-center-name $dataCenterName
    

    이전 명령은 새 데이터 센터의 시드 노드를 표시합니다.

    데이터 센터 세부 정보를 가져오는 방법을 보여 주는 스크린샷

  9. cassandra.yaml 파일에서 기존 데이터 센터의 시드 노드 구성에 새 데이터 센터의 시드 노드를 추가합니다. 기존 클러스터의 각 노드에 대한 신뢰 저장소에 이전에 수집한 관리형 인스턴스 가십 인증서를 설치합니다. 각 인증서에 keytool 대한 명령을 사용합니다.

    keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
    

    데이터 센터를 더 추가하려면 이전 단계를 반복하지만 시드 노드만 필요합니다.

    중요합니다

    기존 Apache Cassandra 클러스터에 단일 데이터 센터만 있고 이 데이터 센터가 추가된 첫 번째 데이터 센터인 경우 매개 변수 cassandra.yamlendpoint_snitch 설정되었는지 확인합니다GossipingPropertyFileSnitch.

    기존 애플리케이션 코드가 일관성을 위해 사용하는 QUORUM 경우 다음 단계에서 복제 설정을 변경하기 전에 기존 애플리케이션 코드가 기존 클러스터에 연결하는 데 사용하는LOCAL_QUORUM 지 확인합니다. 그렇지 않으면 다음 단계에서 복제 설정을 변경한 후 라이브 업데이트가 실패합니다. 복제 전략을 변경한 후에 원하는 경우 QUORUM으로 되돌릴 수 있습니다.

  10. 마지막으로 다음 Cassandra 쿼리 언어 쿼리를 사용하여 클러스터 전체의 모든 데이터 센터를 포함하도록 각 키스페이스의 복제 전략을 업데이트합니다.

    ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3};
    

    또한 여러 시스템 테이블을 업데이트해야 합니다.

    ALTER KEYSPACE "system_auth" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
    ALTER KEYSPACE "system_distributed" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
    ALTER KEYSPACE "system_traces" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
    

    기존 클러스터의 데이터 센터가 SSL(클라이언트-노드 암호화)을 적용하지 않고 애플리케이션 코드가 Apache Cassandra용 Azure Managed Instance에 직접 연결하려는 경우 애플리케이션 코드에서 TLS/SSL을 사용하도록 설정해야 합니다.

실시간 마이그레이션에 하이브리드 클러스터 사용

위의 지침은 하이브리드 클러스터를 구성하는 방법에 대한 지침을 제공합니다. 이 접근 방식은 중단 없는 원활한 마이그레이션을 달성하는 좋은 방법이기도 합니다. 다음 절차에서는 가동 중지 시간이 0인 온-프레미스 또는 다른 Cassandra 환경을 Apache Cassandra용 Azure Managed Instance로 마이그레이션하는 방법을 보여 줍니다.

  1. 하이브리드 클러스터를 구성합니다. 이전 지침을 따릅니다.

  2. 마이그레이션하는 동안 Apache Cassandra용 Azure Managed Instance에서 자동 복구를 일시적으로 사용하지 않도록 설정합니다.

    az managed-cassandra cluster update \
      --resource-group $resourceGroupName \
      --cluster-name $clusterName --repair-enabled false
    
  3. Azure CLI에서 다음 명령을 사용하여 새 Azure Managed Instance for Apache Cassandra 데이터 센터의 각 노드에서 nodetool rebuild 명령을 실행합니다. 노드의 IP 주소로 바꿉니다 <ip address> . 기존 데이터 센터의 이름 <sourcedc>을(를) 마이그레이션할 데이터 센터의 이름으로 바꿉니다.

    az managed-cassandra cluster invoke-command \
      --resource-group $resourceGroupName \
      --cluster-name $clusterName \
      --host <ip address> \
      --command-name nodetool --arguments rebuild="" "<sourcedc>"=""
    

    이전 단계를 모두 수행한 후에만 이 명령을 실행합니다. 이 방법은 모든 기록 데이터가 Apache Cassandra용 Azure Managed Instance의 새 데이터 센터에 복제되도록 해야 합니다. 하나 이상의 노드에서 동시에 실행할 rebuild 수 있습니다. 한 번에 한 노드에서 실행하여 기존 클러스터에 미치는 영향을 줄입니다. 클러스터가 추가 I/O 및 네트워크 압력을 처리할 수 있는 경우 여러 노드에서 실행합니다. 대부분의 설치에서는 클러스터를 오버로드하지 않도록 한두 개만 병렬로 실행할 수 있습니다.

    경고

    를 실행할 nodetool rebuild때 원본 data center 을 지정해야 합니다. 첫 번째 시도에서 데이터 센터를 잘못 제공하면 비시스템 테이블에 대한 데이터를 복사하지 않고 토큰 범위가 복사됩니다. 데이터 센터를 올바르게 제공하는 경우에도 후속 시도가 실패합니다. 이 문제를 해결하려면 Azure Managed Instance for Apache Cassandra 데이터 센터에 있는 system.available_ranges의 각 비시스템 키스페이스에 대한 항목을 cqlsh 쿼리 도구를 사용해서 삭제하십시오.

    delete from system.available_ranges where keyspace_name = 'myKeyspace';
    
  4. Azure Managed Instance for Apache Cassandra 데이터 센터의 시드 노드를 가리키도록 애플리케이션 코드를 잘라냅니다.

    하이브리드 설정 지침에서도 설명한 것처럼 기존 클러스터의 데이터 센터가 SSL(클라이언트-노드 암호화)을 적용하지 않는 경우 애플리케이션 코드에서 이 기능을 사용하도록 설정합니다. Apache Cassandra용 Azure Managed Instance는 이 요구 사항을 적용합니다.

  5. 이전과 동일한 방식으로 각 키 영역에 대해 실행 ALTER KEYSPACE 합니다. 이제 이전 데이터 센터를 제거할 수 있습니다.

  6. 각 이전 데이터 센터 노드에 대해 노드 도구 서비스 해제 를 실행합니다.

  7. 필요한 경우 또는 선호하는 경우 애플리케이션 코드를 다시 QUORUM전환합니다.

  8. 자동 복구를 다시 활성화:

    az managed-cassandra cluster update \
      --resource-group $resourceGroupName \
      --cluster-name $clusterName --repair-enabled true
    

문제 해결

Azure CLI를 사용하여 가상 네트워크에 권한을 적용할 때 오류가 발생하는 경우 Azure Portal에서 수동으로 동일한 권한을 적용할 수 있습니다. 이러한 오류의 예로는 "그래프 데이터베이스에서 사용자 또는 서비스 주체를 찾을 수 없습니다e5007d2c-4b13-4a74-9b6a-605d99f03501."가 있습니다. 자세한 정보를 보려면 Azure Portal을 사용하여 Azure Cosmos DB 서비스 주체 추가하기를 참조하세요.

Azure Cosmos DB 역할 할당은 배포 목적으로만 사용됩니다. Apache Cassandra용 Azure Managed Instanced에는 Azure Cosmos DB에 대한 백 엔드 종속성이 없습니다.

리소스 정리

이 관리되는 인스턴스 클러스터를 계속 사용하지 않려면 다음 단계에 따라 삭제합니다.

  1. Azure Portal의 왼쪽 메뉴에서 리소스 그룹을 선택합니다.
  2. 목록에서 이 빠른 시작을 위해 만든 리소스 그룹을 선택합니다.
  3. 리소스 그룹 개요 창에서 리소스 그룹 삭제를 선택합니다.
  4. 다음 창에서 삭제할 리소스 그룹의 이름을 입력한 다음 삭제를 선택합니다.

다음 단계