자료실

Azure 포털 GUI에서 다른 이름

8월 15, 2018 by Jason Aw Leave a Comment

"Badrequest : 가상 네트워크 Public-Azure-East가 존재하지 않음"포털에 표시된 가상 네트워크 이름이 잘못 될 수 있음 #Azure #Azureclassic

오늘, 나는 Azure Portal GUI에서 새로운 것을 배웠다. Azure Classic에서 두 개의 NIC 카드가있는 일부 VM을 고객이 배포 할 수 있도록 도우려고했습니다. 내가 Azure Classic에서 일한 이후로는 아무런 문제가 없다. 내가 2 개의 NIC를 배치하기위한 포털에 GUI 옵션이 없기 때문에 PowerShell을 통해 수행해야했지만 꽤 똑바로 전했다. 기본 지침은 여기에서 찾을 수 있습니다. 그러나 몇 시간 동안 내 머리를 벽에 치고 난 뒤, 나는이 정보를 우연히 발견하게된다. https://thelonedba.wordpress.com/2015/07/17/new-azurevm-badrequest-the-virtual-network-foo-does-not-exist

Azure Portal GUI에서 다른 이름

Azure Portal GUI에서 가상 네트워크의 이름에 대해 말하는 것과 마치 Get-AzureVMNetSite를 실행할 때 반환되는 실제 이름과 완전히 다를 수 있습니다. 이름을 선택하십시오. 본질적으로 Azure Portal GUI에는 다른 이름이 있습니다. 왜 그런가? 아래 스크린 샷을 참조하십시오. 내가 만든 "Public-Azure-East"라는 가상 네트워크는 실제로 "Group Group Azure Public East"라고 불립니다. Azure Portal GUI에 다른 이름이있는 이유와 그 이유는 내 이해를 넘어서는 것입니다. 보시다시피, 가상 머신 생성에 대한 저의 시도는 실패했습니다. "BadRequest : 가상 네트워크 Public-Azure-East가 존재하지 않습니다."라고 말하는 것은 내가 사용하는 여러 구독과 관련이 있다는 것을 확신했습니다. 그러나 Azure Portal GUI에 다른 이름을 표시하는 버그로 밝혀졌습니다. Azure 포털 GUI에서 다른 이름 2 개의 NIC가있는 VM을 GUI와 같이 만들 수없는 이유는 완전히 다른 이야기입니다. Clusteringformeremortals.com의 허락을 받아 재현

SQL Server Standard Edition의 재해 복구

8월 12, 2018 by Jason Aw Leave a Comment

2 노드 SQL Server 2012/2014 Standard Edition 클러스터를 재해 복구 용 세 번째 서버로 복제

SQL Server Standard Edition의 재해 복구는 SIOS DataKeeper Cluster Edition에서 가능합니다. 방법은 다음과 같습니다. 많은 사람들이 SQL Server Enterprise Edition의 비용으로 인해 SQL Server Standard Edition에 정착하고 있습니다. SQL Server Standard Edition에는 동일한 기능이 많이 있지만 몇 가지 제한 사항이 있습니다. 한 가지 제한 사항은 AlwaysOn 가용성 그룹을 지원하지 않는다는 것입니다. 또한 클러스터의 두 노드 만 지원합니다. 데이터베이스 미러링이 더 이상 사용되지 않고 Standard Edition에서 동기 복제 만 지원하면 실제로 재해 복구 옵션이 제한적입니다.

SQL Server Standard Edition의 재해 복구

이러한 옵션 중 하나는 SIOS DataKeeper Cluster Edition입니다. DataKeeper는 기존 공유 스토리지 클러스터에서 작동합니다. 이 소프트웨어를 사용하면 동기 또는 비동^기 복제를 사용하여 세 번째 노드로 확장 할 수 있습니다. SQL Server Enterprise를 사용하는 경우 진정한 다중 ^사이트 클러스터의 다른 클러스터 멤버로 세 번째 노드를 추가하기 만하면됩니다. 그러나 SQL Server Standard Edition에 대한 내용이므로 세 번째 노드를 클^러스터에 직접 추가 할 수는 없습니다. 좋은 소식은 DataKeeper를 사용하면 데이터를 3 노드에 복제 ^할 수 있으므로 데이터가 보호됩니다. SQL Server Standard Edition의 재해 복구는 DataKeeper를 사용하여 세 번째 노드를 미러 ^원본으로 온라인 상태로 설정한다는 것을 의미합니다. 다음으로 SQL Server Management Studio를 사용하여 복제 된 볼륨에있는 데이터베이스를 탑재합니다. 고객은 또한이 세 번째 노드로 리디렉션되어야^합니다. 그러나 우수한 RPO와 합리적인 RTO를 갖춘 매우 비용 효율적인 솔루션입니다. SIOS 설명서는 SQL Server Standard Edition에 대한 재해 복구 수행 방법에 대해 설명합니다. 여기에서는 최근에 고객 중 한 명을위한 단계를 요약했습니다.

구성

SQL 리소스 중지
SQL 클러스터 리소스에서 실제 디스크 리소스 제거
사용 가능한 저장소에서 물리 디스크 제거
SECONDARY 서버의 온라인 물리 디스크. 드라이브 문자 추가 (없는 경우)
emcmd를 실행하십시오. setconfiguration <드라이브 문자> 256 및 보조 서버 재부트. 이렇게하면 SECONDARY 서버가 E 드라이버에 대한 액세스를 차단하게됩니다. 중요한 단계입니다. 두 대의 서버가 동시에 E 드라이브에 액세스하지 못하도록 방지 할 수 있기를 바랍니다.
PRIMARY 서버의 온라인 디스크
필요한 경우 드라이브 문자 추가
기본에서 DR으로 DataKeeper 미러 만들기 미러를 올바르게 만들려면 모든 서버의 DataKeeper 서버 개요 보고서에서 E 드라이브가 표시되도록 잠시 기다려야합니다. 올바르게 완료되면 PRIMARY에서 DR으로 미러를 생성합니다. 이 프로세스의 일부로 DataKeeper는 복제중인 볼륨을 공유하는 SECONDARY 서버에 대해 묻습니다.

재해의 사건에서 ….

ON DR NODE

EMCMD를 실행하십시오. switchovervolume <드라이브 문자>
처음에는 SQL 서비스 계정에 모든 데이터 및 로그 파일에 대한 읽기 / 쓰기 액세스 권한이 있는지 확인하십시오. 처음으로 데이터베이스를 탑재하려고하면이 액세스 권한을 명시 적으로 부여해야합니다.
SQL Management Studio를 사용하여 데이터베이스 탑재
모든 클라이언트를 DR 사이트의 서버로 리디렉션하십시오. DR 사이트에있는 응용 프로그램을 DR 사이트의 SQL Server 인스턴스를 가리 키도록 미리 구성하는 것이 더 좋습니다.

재난이 끝난 후

메인 사이트의 서버 (PRIMAY, SECONDARY)에 다시 전원을 공급하십시오.
미러가 미러링 상태가 될 때까지 기다립니다.
어떤 노드가 이전 소스인지 확인 (PowerShell을 관리자로 실행). get-clusterresource -Name "<DataKeeper Volume Resource name>"| get-cluster 매개 변수
클러스터에 DataKeeper 볼륨 리소스가 온라인 상태가 아닌지 확인하십시오.
하나의 클러스터 노드에서 DataKeeper GUI를 시작하십시오. 스플릿 브레인 복구 절차 중에 DR 노드가 소스로 선택되도록 모든 스플릿 브레인 조건을 해결합니다 (거의 없음).
이전 소스로보고 된 노드에서 EMCMD를 실행하십시오. switchovervolume <드라이브 문자>
장애 조치 (failover) 클러스터 관리자에서 SQL Server를 온라인으로 가져 오기

위의 단계에서는 SIOS DataKeeper Cluster Edition이 세 서버 (PRIMARY, SECONDARY, DR)에 모두 설치되어 있다고 가정합니다. PRIMARY 및 SECONDARY는 2 노드 공유 저장 영역 클러스터입니다. 로컬로 연결된 저장소가있는 독립 실행 형 SQL Server 인스턴스 (클러스터의 일부가 아님) 인 DR에 데이터를 복제하고 있습니다. 재해 복구 서버에는 공유 클러스터 볼륨과 크기 및 드라이브 문자가 같은 볼륨이 있습니다. 이는 잘 작동하며 재해 복구 사이트를 구성하지 않은 경우에도 클라우드에있는 대상에 복제 할 수 있습니다. SAN을 완전히 제거하려는 경우 모든 복제 된 저장소를 사용하여 동일한 구성을 구축 할 수도 있습니다. 다음은 SQL Server Standard Edition의 재해 복구에 사용할 수있는 구성 중 일부를 보여주는 멋진 짧은 비디오입니다. http://videos.us.sios.com/medias/aula05u2fl Clusteringformeremortals.com의 허가를 받아 복제했습니다.

Azure Resource Manager (ARM)에서 지원되는 서비스

6월 20, 2018 by Jason Aw Leave a Comment

Azure 서비스 관리 (클래식) 또는 Azure Resource Manager (ARM)?

저는 매주 업무상 중요한 작업 부하를 Azure로 이동시키는 사용자를 처리합니다. 내가 보통 묻는 첫 번째 질문은 그들이 Azure Service Management (Classic) 또는 Azure Resource Manager (ARM)를 사용하는지 여부입니다.

나는 보통 ARM을 추천한다. 그것은 새로운 일을하는 방식이며 ARM의 새로운 모든 기능이 개발 중입니다. 그러나 ARM과 아직 호환되지 않는 몇 가지 사항이 있습니다. 시간이 지남에 따라 지원되지 않는 기능 목록이 점점 작아집니다. 그러나 모든 기능을 나열하고 ARM에서 지원되는지 여부를 정기적으로 업데이트하는 것으로 보이는 기존 문서가 있음을 알고있는 것이 좋습니다. https://azure.microsoft.com/en-us/documentation/articles/resource-manager-supported-services/

괜찮은 목록이지만 완벽하지는 않습니다. App Service Environment 페이지에서 App Service Environment가 지원되지 않는다는 것을 발견했습니다.

SQL Server Alwayson 장애 조치 (Failover) 클러스터 인스턴스에서 Azure ILB 연결 수정

6월 19, 2018 by Jason Aw Leave a Comment

SQL Server 장애 조치 인스턴스 클러스터 연결에서 Azure ILB 연결 문제 해결

SQL Server 장애 조치 (Failover) 클러스터 인스턴스 연결 문제를 해결하는 데 도움이되는 다음 도구를 사용합니다. 특히 그 성가신 Azure ILB 연결 문제. 나는 새로운 도구를 찾을 때마다이 기사를 업데이트하려고 노력할 것이다.

NETSTAT

첫 번째 도구는 SQL 클러스터 IP가 수신 대기해야하는 포트에서 수신 대기하는지 확인하는 간단한 테스트입니다. 이 경우 SQL 클러스터 IP 주소는 10.0.0.201입니다. 하지만 포트 1433 인 기본 인스턴스를 사용하고 있습니다.

다음은 액티브 노드가 해당 포트에서 수신 대기 중인지 여부를 빠르게 식별하는 데 도움이되는 명령입니다. 우리의 경우 아래 모든 것이 정상적으로 보입니다.

C :  Users  dave.SIOS> netstat -na | "1433"을 찾는다.
TCP 10.0.0.4 : 49584 10.0.0.201:1433 설립
TCP 10.0.0.4 : 49592 10.0.0.201:1433 설립
TCP 10.0.0.4 : 49593 10.0.0.201:1433 설립
TCP 10.0.0.4 : 49595 10.0.0.201:1433 설립
TCP 10.0.0.201:1433 0.0.0.0:0 LISTENING
설립 됨
TCP 10.0.0.201:1433 10.0.0.4:49592 설립
TCP 10.0.0.201:1433 10.0.0.4:49593 설립
TCP 10.0.0.201:1433 10.0.0.4:49595 설립

일단 SQL이 적절한 포트를 듣고 있는지 확인할 수있게되면 PSPING을 사용하여 포트에 원격으로 연결하려고합니다.

PSPING

PSPing은 Microsoft에서 제공하는 PSTools 패키지의 일부입니다. 보통 도구를 다운로드하고 PSPing을 직접 System32 폴더에 넣으므로 디렉토리를 변경하지 않고도 필요할 때마다 사용할 수 있습니다.

이제 ILB, 클러스터 및 방화벽 관점에서 모든 것이 올바르게 구성되었다고 가정하면 패시브 서버에서 SQL 클러스터 IP 주소와 포트 1433을 ping 할 수 있어야합니다. 아래에 결과가 표시됩니다.

C :  Users  dave.SIOS> psping 10.0.0.201:1433
PsPing v2.01 - PsPing - 핑, 대기 시간, 대역폭 측정 유틸리티
저작권 (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP 10.0.0.201:1433에 연결 :
5 회 반복 (예열 1) 연결 테스트 :
10.0.0.201:1433에 연결 중 (워밍업) : 6.99ms
10.0.0.201:1433에 연결 중 : 0.78ms
10.0.0.201:1433에 연결 중 : 0.96ms
10.0.0.201:1433에 연결 중 : 0.68ms
10.0.0.201:1433에 연결 중 : 0.89ms
일들이 제대로 구성되지 않으면 다음과 비슷한 결과가 나타날 수 있습니다 ...
C :  Users  dave.SIOS> psping 10.0.0.201:1433
TCP 10.0.0.102:1433에 연결 :
5 회 반복 (예열 1) 연결 테스트 :
10.0.0.102:1433에 연결 중 (워밍업) : 
제한 시간이 만료되었으므로이 작업이 반환되었습니다.
10.0.0.102:1433에 연결 중 (워밍업) : 
제한 시간이 만료되었으므로이 작업이 반환되었습니다.
10.0.0.102:1433에 연결 중 (워밍업) : 
제한 시간이 만료되었으므로이 작업이 반환되었습니다.
10.0.0.102:1433에 연결 중 (워밍업) : 
제한 시간이 만료되었으므로이 작업이 반환되었습니다.
10.0.0.102:1433에 연결 중 (워밍업) : 
제한 시간이 만료되었으므로이 작업이 반환되었습니다.

PSPing이 연결되어 있지만 응용 프로그램에서 연결에 문제가있는 경우 조금 더 자세히 조사해야 할 수 있습니다. Great Plains와 같은 일부 응용 프로그램에서도 포트 445에 연결하려고합니다. 응용 프로그램이 연결할 수 없지만 PSPing이 1433에 잘 연결되면. 그런 다음 네트워크 추적을 수행하고 응용 프로그램이 연결하려고하는 다른 포트를 확인해야 할 수 있습니다. 마지막 단계는 해당 포트에 대한로드 밸런싱 규칙을 추가하는 것입니다.

명명 된 인스턴스

명명 된 인스턴스를 사용 하시겠습니까? 고정 포트를 사용하려면 TCP 서비스를 잠그고 있어야합니다. 동시에로드 밸런서에 규칙을 추가하여 SQL Browser 서비스 용 UDP 1434를 리디렉션해야합니다. 그렇지 않으면 명명 된 인스턴스에 연결할 수 없습니다.

파이어 월

TCP 포트 1433 및 59999를 여는 것은 필요한 모든 수동 단계를 다루어야합니다. 그러나 연결 문제를 해결할 때 일반적으로 Windows 방화벽을 꺼서 문제의 가능한 원인으로 방화벽을 제거합니다. 잊지 마세요. Azure에는 Network Security Groups라는 방화벽도 있습니다. 누군가가 트래픽을 차단할 수있는 기본값에서이를 변경했다면.

이름 해상도

SQL 클러스터 이름을 ping하십시오. SQL Server 클러스터 IP 주소로 확인되어야합니다. 몇 번 이상 본 적이 있지만 SQL 클러스터 네트워크 이름과 관련된 DNS A 레코드는 DNS에서 신비하게 사라집니다. 그렇다면 DNS의 A 레코드로 SQL Custer 이름과 IP 주소를 읽고 읽습니다.

SQL CONFIGURATION MANAGER

SQL Configuration Manager에는 SQL 클러스터 IP 주소와 포트 1433이 나열되어 있어야합니다. 우연히 명명 된 인스턴스를 설치했다면 당연히 여기에 들어가서 포트를 특정 포트에 고정하고로드 밸런싱 규칙을 해당 포트에 반영해야합니다. AGUR 당 ILB에 대한 Azure ILB 제한으로 인해 명명 된 인스턴스를 사용하는 유효한 이유가 실제로 없습니다. 스스로를 더 쉽게 만들고 SQL의 기본 인스턴스를 사용하십시오. (업데이트 : 2016 년 10 월 현재 ILB 당 여러 개의 IP 주소를 사용할 수 있으므로 클러스터에 SQL 인스턴스가 여러 개있을 수 있습니다.)

Mere Mortals를위한 클러스터링 (Clustering for Mere Mortals)의 허락을 받아 복제했습니다.

SQL Server 장애 조치 (failover) 클러스터 인스턴스의 ARM에서 Azure ILB

6월 15, 2018 by Jason Aw Leave a Comment

AZURE Powershell 1.0을 사용하는 SQL Server 장애 조치 (failover) 클러스터 인스턴스 또는 AG의 경우 ARM에서 #AZURE ILB 구성

이전 게시물에서는 SQL Server 장애 조치 (failover) 클러스터 또는 AG 리소스에 대해 ARM에서 Azure ILB를 구성하는 방법에 대해 자세히 설명했습니다. 이 기사의 지침은 Azure PowerShell 1.0의 GA 이전에 작성되었습니다. Azure PowerShell 1.0을 사용하면 ILB를 만드는 기본 스크립트가 약간 다를 필요가 있습니다. 나머지 기사는 여전히 정확합니다. 그러나 Azure PowerShell 1.0 이상을 사용하는 경우 해당 기사에서 설명하는 ILB를 작성하는 스크립트는 다음과 같아야합니다.

# 아래 나열된 변수의 값을 바꾸십시오.
$ ResourceGroupName = 'SIOS-EAST'# SQL 노드가 배포되는 리소스 그룹 이름
$ FrontEndConfigurationName = 'FEEAST'#이 매개 변수에 이름을 지정할 수 있습니다.
$ BackendConfiguratioName = 'BEEAST'#이 매개 변수에는 이름을 지정할 수 있습니다.
$ LoadBalancerName = 'ILBEAST'# 내부 로컬 잔액 개체의 이름 지정
$ Location = 'eastus2'# SQL 배치의 데이터 센터 위치 입력
$ subname = 'public'# SQL 노드가있는 서브넷 이름을 제공하십시오
$ ILBIP = '10 .0.0.201 '# 리스너 또는로드 밸런서의 IP 주소 제공
$ subnet = Get-AzureRMVirtualNetwork -ResourceGroupName $ ResourceGroupName | 
Get-AzureRMVirtualNetworkSubnetConfig -name $ subname
$ FEConfig = New-AzureRMLoadBalancerFrontendIpConfig -Name $ FrontEndConfigurationName 
-PrivateIpAddress $ ILBIP -SubnetId $ subnet.Id
$ BackendConfig = New-AzureRMLoadBalancerBackendAddressPoolConfig 
-Name $ BackendConfiguratioName
New-AzureRMLoadBalancer -Name $ LoadBalancerName -ResourceGroupName $ ResourceGroupName 
-Location $ Location -FrontendIpConfiguration $ FEConfig 
-BackendAddressPool $ BackendConfig

원래 기사의 나머지 부분은 동일하지만 사용하기 쉽도록 여기에 복사했습니다 …

GUI 사용

이제 ILB가 생성되었으므로 ILB가 Resource Group의 Azure Portal에서 표시되어야합니다. 아래 그림을 참조하십시오.

SQL Server 장애 조치 (failover) 클러스터 인스턴스의 ARM에서 Azure ILB

PowerShell을 통해 나머지 구성을 완료 할 수도 있지만 필자의 예에서는 GUI를 사용할 것입니다.

PowerShell을 사용하려면이 기사를보고 스크립트를 작성하십시오. 불행히도이 기사는 나를 혼란스럽게합니다. 나는 언젠가 그것을 알아낼 것이고 그것을 사용자 친화적 인 형식으로 문서화하려고 노력할 것이다. 지금은 GUI가 다음 단계에서 유용하다고 생각합니다.

시작하자

아래의 스크린 샷을 따르십시오. 길을 잃은 경우 Azure Portal 상단의 탐색 힌트를 따라 현재 위치를 파악하십시오.

첫 번째 단계

백엔드 풀 설정 탭을 클릭하십시오. 백엔드 풀을 선택하여 가용성 세트 및 가상 시스템을 업데이트합니다. 변경 사항을 저장하십시오.

SQL Server 장애 조치 (failover) 클러스터 인스턴스의 ARM에서 Azure ILB

프로브 탭에서 추가를 눌러로드 밸 랜서의 프로브를 구성하십시오. 프로브 이름을 지정하고 TCP 포트 59999를 사용하도록 구성하십시오. 검사 간격과 비정상적인 임계 값을 기본 설정으로 유지했습니다. 즉 ILB가 장애 조치 후 활성 노드 목록에서 수동 노드를 제거하기까지 10 초가 걸립니다. 클라이언트가 새 활성 노드로 리디렉션되는 데 최대 10 초가 걸릴 수 있습니다. 변경 사항을 저장하십시오.

SQL Server 장애 조치 (failover) 클러스터 인스턴스의 ARM에서 Azure ILB

다음 단계

로드 균형 조정 규칙 탭으로 이동하여 새 규칙을 추가하십시오. 규칙에 적절한 이름을 지정하십시오 (SQL1433 또는 기타). TCP 프로토콜 포트 1433을 선택합니다 (SQL Server의 기본 인스턴스를 사용한다고 가정). 백엔드 포트로 1433을 선택하십시오. 백엔드 풀의 경우 이전에 만든 백엔드 풀을 선택합니다 (BE). 프로브의 경우 이전에 생성 한 프로브도 선택합니다.

세션 지속성은 사용하지 않으려하지만 플로팅 IP (직접 서버 리턴)를 사용하고자합니다. 유휴 시간 제한을 기본 설정으로 두었습니다. 이 값을 최대 값으로 늘리는 것이 좋습니다. 이유는 연결이 끊어지고 다시 설정되어야 할 때마다 SAP 로그 오류 메시지와 같은 일부 응용 프로그램을 보았다는 것입니다.

SQL Server 장애 조치 (failover) 클러스터 인스턴스의 ARM에서 Azure ILB

이 시점에서 ILB가 구성됩니다. SQL Server 장애 조치 (Failover) 클러스터에 필요한 마지막 단계는 단 하나입니다. Classic IP 배포 모델에서 SQL IP 클러스터 리소스를 업데이트해야합니다. 이를 수행하려면 클러스터 노드 중 하나에서만 다음 PowerShell 스크립트를 실행해야합니다. 참고, SubnetMask = "255.255.255.255"는 실수가 아닙니다. 실제 서브넷 마스크와 상관없이 32 비트 마스크를 사용하십시오.

최종 노트 1 개

초기 테스트에서 위의 모든 단계를 완료 한 후에도 여전히 SQL 리소스 이름에 연결할 수 없었습니다. 몇 시간 동안 벽에 머리를 꽂고 나면 SQL 클러스터 이름 리소스가 DNS에 등록되지 않은 것을 발견했습니다. 내가 어떻게되었는지 확실하지 않거나 일관되게 일어날 지 모르겠지만 연결에 문제가 있다면 확실하게 DNS를 확인하고 SQL 클러스터 이름과 IP 주소를 새 A 레코드로 추가합니다 (아직없는 경우).

그리고 물론 좋은 Windows 방화벽을 잊지 마세요. 당신은 1433과 59999에 대한 예외를 만들거나 내가했던 것처럼 모든 것이 올바르게 설정 될 때까지 그냥 꺼야합니다. 어쨌든 로컬 Windows 방화벽 대신 Azure Network Security Groups를 활용하여 모든 Azure 리소스에 대해보다 통일 된 경험을 얻고 싶을 것입니다.

행운을 빌어 어떻게 만들어 지는지 알려주세요.

SIOS가 SQL Server 장애 조치 (Failover) 클러스터를 만드는 방법에 대해 전 세계 기업들에게 어떻게 도움이되는지 확인하려면 여기로 이동하십시오.

Mere Mortals를위한 클러스터링 (Clustering for Mere Mortals)의 허락을 받아 복제했습니다.