Share via


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

첫번째 이야기 – SCCM 2012 SP1에서의 Unix/Linux 지원

SCOM에 이서 SCCM도 타 기종 지원을 시작하게 되나 봅니다. MMS 2011에서 첫 공식 발표가 이루어졌습니다.

내년 초에 MMS 2012에서 System Center 2012가 공식 발표될 예정입니다만, 이 때 지원되기보다는 Service Pack으로 차후에 지원될 예정으로 얘기되고 있습니다.

 

두번째이야기 – SCOM DB, DW의 Retention 기간

기본으로 SCOM DB는 7일, DW는 400일입니다.

SCOM DB의 기간 변경은 SCOM console에서 가능한데, DW의 기간 변경은 직접 DW에 접근해서 변경해야 합니다.

일단 현재 설정된 값을 알아보는 SQL 쿼리 문은 아래 블로그에서

https://blogs.technet.com/b/jonathanalmquist/archive/2009/11/28/dw-retention-and-groom-settings.aspx

값의 변경 방법은 아래 블로그를 참조하시면 됩니다.

https://blogs.technet.com/b/momteam/archive/2008/05/14/data-warehouse-data-retention-policy-dwdatarp-exe.aspx

하지만, SCOM DB(DW가 아님)의 보관 기간을 늘리는 것은 좋은 프랙티스는 아니라고 봅니다.

SCOM DB의 사이즈가 커지면, 성능 저하나 DB 운영상의 문제점이 발생할 수 있습니다.

6,000대 이상의 시스템 모니터링 하고, 성능 데이터 보관 기간을 확장한 사이트에서 100GB가 넘는 SCOM DB 사이즈가 있긴 하지만, 드문 경우라고 보고요.

대부분의 고객들에 30GB의 DB 사이즈를 권고하고요, 400-600 개 시스템을 모니터링 하는데, 10GB가 넘는 DB를 사용하는 경우는 드물다고 합니다.

 

 

세번째 이야기 – Get-vm powershell 명령어

대규모 VDI 시나리오나 대규모 가상화 서버 시나리오에서 타 제품과 연동하기 위해 SCVMM에 Get-vm 명령어를 자주 사용하게 될 텐데요.

주의사항은 get-vm –name은 직접 DB에 query를 돌려서 수행하기 때문에 오래 걸리고 부하를 많이 주는 비싼 명령어라고 합니다.

Get-vm –ID는 client(콘솔)에 캐시된 DB에서 찾기 때문에 아주 빠르다고 합니다.

또한 콘솔이 서버와의 통신으로 최신 내용임을 보장하기 때문에 최신 내용이 아닐까 걱정할 필요도 없다고 합니다.

특히, VDI 환경에서 수천대의 VM이 있는 경우에 get-vm -name은 피해야할 대표적인 명령어라고 보여집니다.

 

네번째 이야기 – 공통 부모 이미지를 통한 다수의 가상 머신 만들기

테스트랩에서 여러 제품 테스트하다 보니까, 가상 머신이 많아지고 결국 디스크가 부족하게 되는 현상이 발생하는데요.

특히 20GB에 달하는 Windows Server 2008 R2 이미지를 다수 만들다 보면, 나중에 디스크 공간 부족으로 어려움이 발생하지요.

이를 해결하는 방법이 아래 링크에 되어 있는 공통 부모 이미지로 다수의 가상 머신 만들기 입니다.

이는 VDI 시나리오에서도 적용이 가능한 시나리오라고 봅니다만,

문제는 관리입니다. 시간이 지나서 patch와 Service Pack을 적용하면 Diff 이미지도 엄청나게 커져서 공통부모 이미지로 절약되는 공간이 의미가 없어지는 것 같습니다.

또한, migration도 스크립트로 만들어야 합니다.

성능은 기존의 Diff. Hard disk를 사용하는 것과 큰 차이는 없을 것이라고 생각됩니다.

https://blogs.technet.com/b/danstolts/archive/2011/01/13/using-differencing-disk-and-sysprep-image-to-create-hyper-v-guest-on-windows-server-2008-r2-by-dan-stolts.aspx

 

다섯번째 이야기 – SCOM Management Server의 Cache 사이즈

DB가 다운되었을 때, SCOM Management Server는 어떤 반응을 보일까요.

일단, 자체 저장소에 보관을 합니다. 약 1일 정도의 로그를 보관할 수 있는 100MB가 기본이고요(사이트마다 양은 틀리겠지요)

하루가 넘어 저장소가 부족하면 성능데이터를 덮어 씁니다. Alert는 지우지 않고요.

하지만, 기간이 길어지면 결국 과거 데이터는 모두 엎어치게 됩니다.

 

여섯번째 이야기 – Dynamic Disk의 성능이 안 좋은 이유

Dynamic Disk는 참 매혹적입니다. 아까운 Storage를 절약할 수 있으니까요.

하지만, Production에서는 꺼려집니다. 바로 성능과 Trade-off를 해야 하니까요.

최근 MS의 테스트 자료를 보면 Dynamic disk의 성능이 Fixed disk와 큰 차이가 없어 보일 정도로 개선된 리포트도 보셨을 겁니다만,

현실로는 그렇지 않습니다. 아래와 같이 Dynamic disk의 성능상의 단점이 있습니다.

  1.  Space를 증가할 때, NTFS의 특성상 footer 부분을 뒤로 옮기면서 해당 space를 Zero로 채우는 IO 추가 발생
  2.  가상 디스크와 실제 디스크의 mis-alignment 발생 (하나의 IO가 실제로 두개의 IO로 발생함)
  3.  Dynamic disk의 메타데이터를 끊임없이 관리해야 하는 오버로드  

위의 증상은 Hyper-V에만 나타나는 것이 아니라 대부분의 가상환경에서 나타난다고 합니다.

 

일곱번째 이야기 – Server App-V blog 개설

SCVMM 2012에서 새로이 나온 시나리오가 Server App-V입니다.

과거 이메일에서도 잠깐 설명을 드렸는데, 해당팀에서 블로그를 열었습니다.

미리 한번 어떤 Server Application을 가상화하는가를 보실 수 있을 것입니다.

https://blogs.technet.com/b/serverappv/archive/2011/04/08/what-types-of-applications-should-i-virtualize-with-server-app-v.aspx

 

여덟번째 이야기 – 인텔의 최근 CPU Sandy Bridge와 Hyper-V

인텔에서 i3/i5/i7 기반의 2세대 프로세스가 발표되었습니다. 첫 발표는 데스크탑 프로세서 위주로 발표되었지만, 곧 서버 기반의 프로세서도 발표될 예정입니다.

여기서 얘기하는 이유는 Windows Server 2008 R2가 발표된 후에 나온 CPU이기 때문에,

Hyper-V Role을 설정할 때 에러가 발생합니다.

Hyper-V는 알지 못하는 CPU에 대해서 동작하지 말도록 설계되었기 때문입니다.

이런 CPU에서 Hyper-V를 사용하기 위해서는 SP1을 적용하거나,

Hotfix를 적용해야 합니다. Hotfix를 적용하면 가상서버에서 신규 CPU의 기능(AVX 등)을 사용하지 못하는 단점이 있습니다.

SP1을 적용하면 가상머신도 신규 기능을 사용할 수 있습니다.

헌데 SP1을 적용하고도 서버의 성능이 저하되는 경우가 발생합니다.

이때는 추가적으로 Hotfix를 적용해야 하는데, 아래 KB을 읽고 이메일을 보내면 QFE가 답변으로 보내집니다.

https://support.microsoft.com/kb/2517329