자료실

Internet Explorer 11을 Bing To Google로 변경하십시오.

8월 15, 2018 by Jason Aw Leave a Comment

Internet Explorer 11에서 기본 검색 공급자 변경 빙에서 Google # IE11 # GOOGLE #BING

IE 11을 여전히 사용하는 사용자에게는 최근 업데이트로 기본 검색 공급자가 Bing으로 변경되었을 수 있습니다. Bing To Google에서 Internet Explorer 11을 변경하는 방법을 찾으려면 계속 읽으십시오. Microsoft는 보안 기능을 향상 시켰습니다. 악성 소프트웨어가 기본 검색 엔진과 홈 페이지를 변경함으로써 브라우저를 하이재킹하는 것을 막기를 희망하고 있습니다. 저는 최신 맬웨어를 다운로드 할 십대 인 십대 "게이머"의 아빠입니다. 그래서 나는 추가 된 보안에 대해 감사하고 있지만, 약간의 걱정거리가 있습니다. 이 보안 업데이트의 "이점"중 하나는 기본 검색 공급자가 현재 Bing입니다. 다시 Google로 전환하는 것은 1-2-3만큼 쉽지 않습니다. Microsoft는 자신의 기사에서 Internet Explorer 11을 Bing To Google에서 Internet Explorer 11로 변경하는 방법에 대한 단계를 다음과 같이 게시합니다. http://windows.microsoft.com/ko-kr/windows-10/internet-explorer-11-settings-protection 나를 생각해라. 나는 Microsoft 제품을 좋아합니다. 그러나 불행히도 Bing은 일반적으로 매우 구체적인 기술 내용을 찾고있는 검색 유형에 대해 친숙하지 않습니다. 나는 빙 (Bing)이 소비자 친화적 일 수 있다고 생각한다. 그러나 Google은 검색 엔진 전쟁으로 저에게 답변을 제공합니다.

Internet Explorer 11을 Bing To Google로 변경하십시오.

Internet Explorer 11을 Bing에서 Google로 변경하려면이 기사의 다음 단계를 따르십시오. 아래의 스크린 샷은 단계를 보여줍니다. Internet Explorer 11을 Bing To Google로 변경하십시오.

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)의 허락을 받아 복제했습니다.