Condividi tramite


윈도우서버와 시스템센터 기술 정보 - 007

 Windows Server 이야기

1. NLB가 과연 얼마만큼 로드 밸런싱 효과가 있을까?

Load balancing하면 항상 L4 이상의 고가의 하드웨어 장비만을 생각했지요. 하지만, 대부분의 기업이 실제로 값비싼 L4 장비를 이용할 만큼의 대규모 성능 좋은 부하분산이 필요하지 않다고 봅니다.

아래 링크는 Windows 2000 버전의 이야기이지만, 시사하는 바가 있다고 생각합니다. 특히  2008로 들어서면서 NLB의 기능이 보강된 만큼 아래 링크 이상의 안정성과 성능의 보강이 이루었다고 생각이 듭니다. 나중에 기회가 되면 NLB에 대한 특집을 만들고 싶습니다.

https://technet.microsoft.com/en-us/library/bb742455.aspx#XSLTsection124121120120

2. 가상 호스트와 물리 호스트 간의Cluster 지원

가능할까요? MS에서 지원하는 것일까요? 답은 예스입니다. 이는 Windows 2008로 오면서 Cluster 지원 원칙이 바뀝니다.(단지 이름이 MSCS에서 WSFC로 바뀐게 아니지요.)

MS는 Failover Cluster가 다음의 원칙을 준수하면 기술지원이 됩니다.

(1)   서버 하드웨어가 Windows 지원 Logo가 있어야 한다.

(2)   Cluster Manger 프로그램의Validate를 통과해야 합니다.

단, SQL 서버의 경우, 2009년까지 위의 설정을 지원하지 않고 있네요. 따라서, Workload 별로 지원 여부를 또 따져 봐야 하는 필요성이 있습니다.

 

Hyper-V 이야기

1. Hyper-V 보안 이야기

가상화를 구축할 때, 일반적인 원칙이 보안 수준이 다른 가상 머신을 하나의 호스트에 두지 말아라 입니다. 큰 대기업은 문제가 없지만, SMB에서는 많지도 않은 서버 가상화를 하기 위해서 DMZ와 Internal 네트워크에 호스트를 따로 구축하는 것이 가상화로 인한 비용절감에 보탬이 되지 않는 다는 것이죠. 이럴때, 가장 간단하게는 VLAN을 이용해서 네트워크를 분리할 수도 있을 것이고, 좀 더 보안을 강화하기 위해서 네트워크 인터페이스 카드를 분리할 수도 있겠습니다. 좀 더 보안이 필요한 곳은 어쩔 수 없이 물리적인 서버를 분리해야 겠지요.

흥미로운 질문 중 하나는 VMBus를 통해서 Guest OS들이 물리적 장치의 IO를 직접 접근하는데, 그렇다면 보안 수준이 다른 Guest OS들이 공통의 VMBus를 이용해서 보안 수칙에 어긋나는 것이 아니냐는 질문입니다. MS의 대답은 VMBus는 공유되지 않는다 입니다. 개별 Guest OS는 자신만의 VMBus를 가지고 IO를 수행하므로 우려하는 보안 문제는 발생하지 않습니다.

참고로 Hyper-V와 관련된 파일 및 서비스 포트에 대한 정보 파일입니다.

https://download.microsoft.com/download/8/2/9/829bee7b-821b-4c4c-8297-13762aa5c3e4/Windows%20Server%202008%20Hyper-V%20Attack%20Surface%20Reference.xlsx

아시겠지만, Windows 8에서는 가상화 수준에서의 네트워크 격리가 훨씬 더 강화되어 네트워크 수준에서의 보안 우려가 줄어들고, 보안 관리 기능도 대폭 강화될 예정입니다.

2. Best Practice: SQL 및 Sharepoint의 가상화

가상화 대상을 선정할 때 항상 나오는 것이 SQL일 것입니다. Windows 플랫폼을 사용하는 고객 중 SQL을 사용하지 않는 고객이 없을테니까요. SQL을 가상화 해야 하는가에 대해서는 MS는 상황에 따라 다르다라는 것이 답이겠지요. IO나 CPU부담이 크지 않은 SQL의 경우 why not이겠지요. 아래는 성능도 나쁘지 않다는 문서입니다.

Running SQL Server 2008 in a Hyper-V Environment. Best Practices and Performance Considerations

MS IT에서는 어떻게 SQL 가상화 프로젝트를 진행했을 까요. 바로 아래 링크에서 why 와 how가 소개됩니다. 2008 R2가 아닌게 아쉽지만…

https://technet.microsoft.com/en-us/library/dd557540.aspx

다음은 Sharepoint의 가상화와 관련된 정보입니다.

https://technet.microsoft.com/en-us/library/cc816955(office.12).aspx

https://technet.microsoft.com/en-us/library/dd277865(office.12).aspx

3. Hyper-V 상의 부하 테스트

Hyper-V PoC를 수행할 경우, 종종 부하 테스트를 고객이 문의할 수 있습니다. 이때 이용가능한 툴을 소개합니다.

SQL:  https://support.microsoft.com/kb/231619

Web: https://support.microsoft.com/kb/231282

Exchange 2010: https://technet.microsoft.com/en-us/library/dd335108.aspx

File and I/O: https://www.iometer.org/

4. Hyper-V 모니터링

Hyper-V 가 잘 동작하는지 보기 위해서 무엇을 모니터링 해야 하는가? 이에 대한 정리된 블로그가 있어 소개해 드립니다.

https://blogs.msdn.com/b/tvoellm/archive/2009/04/23/monitoring-hyper-v-performance.aspx

https://blogs.msdn.com/b/tvoellm/archive/2009/12/18/hyper-v-performance-faq-r2.aspx

5. 도메인 콘트롤러 가상화

도메인 콘트롤러는 아주 아주 아주 특별한 시스템이죠. 거의 모든 MS의 인프라가 의존하는 시스템이면서 시간(Time sync)에도 아주 민감합니다. 대표적으로 AD가 다운되면 로컬 계정을 제외하고는 접근이 안 되는 아주 난감한 상황이 발생합니다.

이런 시스템을 가상화 해야 할 까요? 아래 다양한 옵션을 제시하고 있네요.

https://blogs.msdn.com/b/virtual_pc_guy/archive/2008/11/24/the-domain-controller-dilemma.aspx

많은 전문가들이, 도메인서버의 가상화를 비추하곤 합니다. 도메인 콘트롤러의 장애는 너무 심각한 장애이기에…

위의 글을 보면 Hyper-V의 Parent partition에 DC를 설치하는 의견을 많이 제시합니다. 너무나도 상식적인 수준이니까요.

하지만, MS의 답은 항상 같습니다. 권고되지 않는다…--;

6. DM과 Page file 설정

DM… Dynamic Memory입니다. DM은 Page file 설정이 되어 있어야 작동합니다. 만약 Page file이 없다면 DM은 정상 동작하지 않습니다. 그렇다면 DM을 설정했을 때, page file 설정은 어떻게 하는 것이 좋을까요. 답은 기본 설정이 좋다 입니다.

기본 설정은 아래와 같습니다.

Startup Memory

Initial Page File Size

Maximum Page File Size

< 1 GB

1 GB

4 GB

> 1 GB

Startup  Memory

3 * Startup Memory

Page file을 크게 하면 DM에서 소화하지 못할 정도록 급작스럽게 메모리를 요구하는 어플리케이션이 잘 동작할 수 있다고 합니다. 하지만, 이런 어플리케이션은 거의 없다고 합니다. 단, full memory dump를 사용하는 경우에는 DM의 Max memory값으로 Page file 크기를 설정해 주어야 한다고 합니다.

Hyper-V Parent partition에 다른 어플리케이션이나 서버 역할을 추가하지 말아야 할 이유 하나 더 있네요, 바로 Guest partition에 대해서는 CPU 사용에 대한 통제를 할 수 있지만, parent partition에는 CPU 관련 reserve나 limit을 설정 할 수 없네요.

 

VDI 및 Presentation 가상화 이야기

1. Mobile RDP client for iPad/iPhone/iPod

지난번에도 언급한 적이 있지만 모바일 시대가 되면서 Presentation virtualization(VDI 포함)을 구축할 경우, 대중적인 iOS 장비와 안드로이드에 대한 지원을 필수로 하는 고객들이 늘고 있습니다.
현재 SCOM이나 SCCM 다음 버전이 Unix, Linux를 지원하는 추세로 봐서는 RDP도 그렇게 되지 않을까 하지만, 미래는 아무도 모르고 더더군다나 가까운 미래는 아니라는 것이 문제겠지요. 이런 경우에 MS는 Citrix와 파트너를 이루는 것을 기본 정책으로 하고 있습니다.
하지만, Citrix는 좀 고가이지요. 따라서, 단순히 고객이 모바일 장비에 대한 RDP Client를 요구할 경우에 저렴하게 사용할 수 있는 제품이 있네요.

https://itap-mobile.com/itap-rdp 안드로이드도 지원하고요. NLA, RD Gateway 등을 지원하네요. RemoteFX 지원도 연내에 하겠다는데 모르지요.

단, 리눅스를 포함해서 MS에서 정식 제공해주는 라이브러리를 사용하지 않고 Reverse 엔지니어링을 이용한 것이라 MS의 정식 지원은 힘들 수 있습니다. 하지만, 몇 년동안 제품을 팔아오고 지원도 괜찮다는 평이네요.

(본인과 MS는 이 제품과 전혀 관계가 없고, 책임도 없습니다. ^^;)

참고로 현재 RDP 소스는 Windows 용과 Mac 용이 공개되는 프로그램이 있습니다.

https://blogs.msdn.com/b/rds/archive/2010/08/16/rdp-client-reference-source-code-now-available-to-rdp-licensees.aspx

https://blogs.msdn.com/b/rds/archive/2011/03/16/mac-rdp-source-code-now-available-to-rdp-licensees.aspx

 

2. VDI 시나리오에서 클라이언트 OS 대신 서버 OS 사용하기 (권고되지 않습니다.)

고객들이 VDI를 구축하면서 클라이언트 OS 대신 서버 OS를 사용하길 원하는 경우가 있습니다. 일례로 Windows Server 2008 R2 Data Center 버전을 사용하면 무제한의 Guest OS를 만들 수 있으므로 이점이 있을 수 있다는 거지요.

하지만, 몇 가지 고려 사항이 있습니다. 일단 서버 OS를 사용하게 되면 VDI 시나리오에서는 MS에서는 테스트를 수행하지 않았으므로 지원이 어려울 수 있습니다. 또한, 대다수의 상용 어플리케이션들은 역시 서버 OS를 지원하지 않는 경우가 많고, 문제가 발생할 때 지원 받을 수가 없습니다.

 

3. MS VDI에서 용량 산정 및 고가용성

MS의 제품들은 대부분 고객들을 신뢰하여 라이선스 관련하여 까다롭지 않습니다.
그 예외 중의 하나가 RDS이지요. 만약 License server에 장애가 생기면 상황에 따라서 client의 연결에도 장애가 발생할 수 있습니다 .per user와 per device 모드에 따라 장애 정도가 다르겠지만서도요. Connection Broker도 마찬가지로 장애 여파가 클 수 있습니다.

전체 요소별 고가용성을 고려한 블로그가 있네요.

https://blogs.msdn.com/b/rds/archive/2010/03/01/microsoft-vdi-high-availability-deployment-options.aspx

RD Session Host in redirection mode는 DNS round robin으로… 완벽한 고가용성을 위해서는 L4 같은 장비라 필요할 수 있겠네요.

RD Connection Broker는 MSFC가 지원하는 서비스 중의 하나로 고가용성 구축이 용이하네요. 아래 링크를 참조하시고요.

https://blogs.technet.com/b/mghazai/archive/2010/05/12/windows-server-2008-r2-highly-available-clustered-remote-desktop-connection-broker.aspx

RD Virtualization Host는 익히 다 아는 Hyper-V Cluster로…

RD Web Access는 웹서버니까 NLB가 답이 될 거고요.

RD Gateway의 용량 산정 및 고가용성과 관련된 링크는 아래에 있습니다. NLB로 고가용성을 구축할 수 있고요.

https://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=d31ac8fd-6ad8-4c5e-8dc3-a93fb55abc76

RD License server의 고가용성은 개별 RDSH 차원에서도 구현 가능합니다. RDSH에 등록된 License server를 차례대로 접근하여 License를 받습니다. 또는 당연하지만, Hyper-V 클러스터에 VM으로 올리면 자동으로 고가용성이 된다고 얘기합니다…^^;

또는 2개의 License server를 구축하여 반반씩 라이선스를 입력하는 방법도 고려될 수 있겠네요. 추가적으로 아래 링크를 참조하시고요. 2008버전은 아닙니다만 참고하실 수 있을 것 같습니다.

https://www.virtualizationadmin.com/articles-tutorials/terminal-services/licensing/terminal-services-license-server-high-availability-recovery-part1.html

RD Session Host의 용량 산정과 관련된 링크는 아래에 있습니다.

https://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=ca837962-4128-4680-b1c0-ad0985939063

 

4. RDS에서 Mouse가 느리게 움직이는 현상

RDS상에서 CAD 프로그램등을 실행하면 CAD 프로그램의 어떤 객체들이 Mouse 포인트를 느리게 쫓아가는 경향이 있습니다.
이는 RDP에서 기본 Mouse 정보를 120ms마다 보내주기 때문입니다. 이를 개선하기 위해서는 아래 링크를 보시면 Registry값을 변경해 주는 정보가 있습니다. 여기서 “Min Send Interval”이 바로 그 시간을 설정하는 값입니다. 값이 적을수록 네트워크 부하가 클 테니, 서서히 줄여가면서 테스트해 보시기 바랍니다.

https://blogs.technet.com/b/askperf/archive/2009/04/17/terminal-services-and-graphically-intensive-applications.aspx

저는 10으로 바꾸고 테스트 했더니 아래와 같은 결과를 얻을 수 있었습니다.

똑 같은 마우스 움직임인데, RDS에서의 Paint프로그램은 전혀 다른 움직임으로 인식합니다.(왼쪽-기본값, 오른쪽-10ms로 변경)


  
  
5. RD Connection Broker의 RDSH failure 탐지

RD Connection Broker는 RDSH에 대해서 부하 분산과 고가용성을 제공합니다. RDSH farm에서 하나의 RDSH가 장애가 발생하면 해당 RDSH에 새로운 연결을 제공하지 않습니다. 사용자가 연결 중에 장애가 발생한 경우에 사용자를 자동으로 다른 RDSH에 연결시켜 주지는 않습니다. 사용자가 재 연결을 해야 합니다(현재 MS VDI 아키텍처로 당연한 거겠지요). 또한 RDCB는 W2K8 R2에서 기본으로 매 120초마다 RDSH를 체크합니다. 이 값을 바꿀수는 있지요. 만약 이 Ping이 실패를 하면 5초간격으로 2번 더 보내고 그래도 응답이 없으면 해당 RDSH를 장애로 보고 더 이상 신규 연결을 연결해 주지 않습니다.

System Center Operations Manager

1.  비밀스런 OpsMgr의 DB Schema

OpsMgr의 DW에 대한 schema는 공개되어 있습니다. 아래와 같이.

https://technet.microsoft.com/en-us/library/gg508713.aspx

하지만 DB의 schema는 공개되지 않았습니다. 두 가지 이유가 있네요.

  1.  모든 정보는 DW에 다 있다.
  2.  OpsMgr의 성능과 안정성에 중요한 DB는 직접 접근하지 말아라.

System Center Virtual Machine Manager

1.  가상 머신별 권한 통제

가상 머신별로 관리자를 따로 두기 위해서는 권한 관리를 수행해야 합니다. Hyper-V에서는 azman.msc를 통해서 이를 수행합니다. 하지만, 관리자가 호스트에 관리자 권한을 가지고 있으면 이를 변경할 수 있는 문제가 발생합니다. 이런 현실적인 어려움을 감안하여 MS IT에서는 호스트의 관리자는 모든 가상 머신에 접근할 수 있다는 정책을 가지고 있습니다. 따라서, domain controller와 같은 보안에 민감한 장비는 완전히 따로 관리되어야 겠지요.

SCVMM에서는 자체적인 접근 통제 메커니즘을 가지고 있습니다. 하지만, SCVMM이 바로 azman.msc를 이용하여 접근 통제를 구현하고 있다는 것입니다. 따라서, SCVMM의 접근 통제와 Hyper-V상의 azman.msc가 따로 동작할 수 없다라는 것입니다. SCVMM이 기존의 Hyper-V azman.msc의 내용을 덮어 쓰게 됩니다.