Maystyle :
Admin : New post
Guestbook
Local
media
Catergories
Recent Articles
Recent Comments
Recent Trackbacks
Calendar
Tag
Archive
Link
Search
 
해당되는 게시물 6건
  Hyper-v Storage 설정 관련 
작성일시 : 2013.12.27 14:49 | 분류 : Quick Tips

Disk IOPS의 QoS 설정 시 Minimum은 실제 최소한 확보해야 하는 QoS 수치가 아니라 Warning이 발생함

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  Storage Space 구현 시 주의 사항 01 
작성일시 : 2013.12.27 12:08 | 분류 : Quick Tips

Storage Space에서는

과반수의 디스크가 접근이 되어야 한다.
즉 2개의 JBOD로 구현하고 Pool을 각각에서 5:5로 구현한 경우 과반수 확보가 어렵기 때문에 한 JBOD가 죽게 되면 전체 디스크가 죽게 된다. 즉 JBOD는 2개 이상으로 구현해야 한다.

인증된 JBOD가 왜 좋을까?
JBOD의 인증이 제공될 때 종속된 BOX 정보 및 Disk 정보를 제공해 준다. 하지만 인증되지 못한 JBOD의 경우 운이 나쁠 경우 디스크 관리자에서 쭉 BOX와 관계 없이 디스크가 나열 되게 된다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  Hyper-v 2012 R2 기본 부터 고급까지 1. Processor : Scheduling 1st Story 
작성일시 : 2013.12.26 23:55 | 분류 : Cloud/Hypervisor

안녕하세요.
오늘은 좀 더 쉽지 않은 주제인 Virtual Processor에 대한 Scheduling을 다루고자 합니다.

1.1 Virtual Processor VS Logical Processor
1.2 Scheduling 첫 번째 이야기

이미 말씀드린 바와 같이 Hyper-v의 가장 중요한 역활은 바로 Scheduling 입니다.
즉 Virtual Processor를 적절하게 Logical Processor에 할당하는 것이죠. 기본적으로 우리는 VM 별로 할당 정책을 통해 중요한 VM에 대하여 많은 Logical Processor 점유률을 할당 할 수 있는데, 실은 이 뿐만이 아니라 내부적으로Hyper-v는 그보다 정말 많은 사항들 예를 들어 OS Version, Hyper-Threading, Affinity, Guest Spinlock, Physical Numa 등등을 고려하여 최선의 정책을 만들어 내고 적용 하고 있습니다.

그리고 오늘은 우리가 직접 설정할 수 있는 Scheduling Policy 이야기 이전에 그 이면에 무슨 일들이 일어나고 있는지에 대해 이야기 하고자 합니다.

Enlightenment of Scheduling
image

가장 먼저 우리는 VM에 할당될 Virtual Processor의 갯수를 조정할 수 있습니다.
물론 Windows Server 2012 Hyper-v 부터는 VM당 최대 64개의 Virtual Processor을 할당할 수 있죠.
(물론 실제 Logical Processor가 64개 이상일 경우지만)

하지만 아래와 같이 Windows Server 2003의 경우 최대 할당 가능한 Processor의 갯수가 2개로 명시되어 있습니다.
왜 그럴까요?
image
출처 :  http://technet.microsoft.com/en-us/library/hh831531.aspx

이를 이해하기 위해서는 조금 재미 있는 이야기를 해야 하는데요.
실은 Partition 입장에서는 자신은 하나의 완전한 OS이고 자신이 사용하는 Processor가 Virtual 인지 Physical인지는 중요하지 않습니다. 아니 생각 자체를 하지 않았죠.
그러다 보니 이런 OS들을 가상화 플랫폼에 올리면서 한 가지 재미 있는 사실이 있는데, 바로 VM 별로 Virtual Processor들에 대한 Scheduling을 제공하게 되면 VM 및 Virtual Processor가 증가함에 따라 성능은 Linear 하게 하락한다는 거죠.
예를 들어 LP : VP 의 비율이 1:4 면 1/4 수준의 성능이 1:8이라면 1/8 성능으로 줄어 들게 됩니다. 그런데 여기서 우리는 한가지 질문이 생깁니다.

“어~ 그러고 보니 이 VM의 VP는 8개 인데 지금 2개만 100%구 다른 녀석들은 다 노네…”

내 맞습니다. VP에 대한 Scheduling을 좀더 스마트 하게 하는 방법이 없을까 고민하게 된겁니다.
즉 고전의 OS을 기준으로 한 VM별 Scheduling은 말 그대로 비용의 낭비 즉 사용 하지 않는 LP까지를 VP에 할당함으로써 다른 VM의 Virtual Processor가 점유 할 수 있는 기회를 빼앗아 버린다는거죠.
자 그렇다고 답이 없는건 아닙니다. 이미 이야기한 것과 같이 VM에 종속성을 이야기 하지 않고 Virtual Processor 에만 집중한다면 답이 나올 수도 있죠.

다시 말해 Active 즉 Workload을 실행하는 Virtual Processor에만 Logical Processor을 제공하는 겁니다.
하지만 여전히 문제가 남아 있습니다. 도대체 어떻게 Hyper-v가 그런 Active 한 Virtual Processor 만을 알아내냐는 거죠.

그래서 아예 OS 커널을 수정했습니다. 어떻게? 바로 Hyper-v를 인식하고 Hyper-v가 적절하게 스케줄링 할 수 있도록 스케줄링 정보를 전달하도록 말이죠…
그리고 이를 우리는 Enlightenment 라고 부릅니다.
문제는 Windows Server 2003의 경우 Hyper-v 출시 이전에 출시된 OS라는 점입니다.
Hyper-v 출시 이후의 OS야 어차피 처음 설계 단계에서부터 가상화를 고려하여 디자인 되었기 때문에 위에서 말씀 드린 것과 같이 필요한 Scheduling 정보를 Hyper-v에 제공하게 됩니다. 하지만 그 이전의 OS의 경우에는 그렇지 못하겠죠. 그러다 보니 성능에 미치는 영향을 최소화하게 위해 Windows Server 2003의 경우 최대 VP의 갯수를 2개로 제한하고 있는 것이죠.

Enlihtenment의 예에는 위의 Active Virtual Processor에 대한 인식에 관한 사항 외에도 만약 VM의 특정 VP (Virtual Processor)가 Spinlock에 걸린 경우 해당 Lock이 풀릴 때까지 기다릴 수 있도록 정보를 제공하기도 합니다.

자 그리고 이렇게 Partition과 Hyper-v와의 통신을 위해서는 바로 Hypercall이 사용되게 되죠.

자 그 외에는 다른 어떤 사항들을 고려하게 될까요?

Affinity

분명히 Virtual Processor 역시 Processor 입니다.
그렇기 때문에 자주 접근되는 데이터의 경우 Processor Cache에 직접 넣어놓고 사용하게 되죠.
만약 Virtual Processor가 할당되던 Logical Processor가 바뀐다면? 당연히 이 Processor Cache는 모두 사라지게 되고 그만큼 성능에는 악 영향을 끼치겠죠?
그렇기 때문에 Hyper-v 는 Processor에 Affinity을 설정하고 항상 지정된 Logical Processor가 할당 될 수 있게 노력하게 됩니다. 물론 최대한 노력해 보고 여의치 않는 경우 다른 LP을 할당 받겠지만요.

Hyperthreading

다음으로 Hyperthreading 입니다.
실은 Hyperthreading이라는 개념은 매우 단순한데 원리는 다음과 같습니다. 실은 우리가 보는 CPU는 단순하지 않습니다. 매우 여러개의 각기 다른 역활을 하는 모듈들로 구성되어 있는데, 저는 일단 간단하게 “명령어를 읽고” “처리하고” “반환하는” 3개의 모듈로만 이루어 져 있다고 가정하고 이야기를 진행 해 보겠습니다.

문제는 이런 CPU가 매우 비싸다는 점입니다.
그럼에 불구하고 하나의 CPU가 “명령어를 읽고” 있다면 다른 모듈들 즉 “처리하고” “반환하는” 다른 모듈들은 쉬고 있다는 거죠. 그래서 과학자들은 생각한 거죠.

“아! 데이터의 흐름 즉 Pipeline을 여러 개 만들자!”

그렇게 되면 당연히 첫 번째 데이터가 처리 또는 반환 하는 동안 다른 데이터가 읽어 질 수 있을 테니깐요.
그렇게 되면 전반적인 CPU 활용률이 높아 지겠죠.
그래서 CPU를 만드는 회사에서는 이 Hyperthreading을 적극적으로 도입했고, 현재 우리가 사용하는 Intel Processor의 경우에는 2개의 Pipeline을 사용하고 있습니다.

하지만 여기에도 문제가 존재했습니다. 바로 Intel Processor가 “CISC” 기반이였다는 거죠. 실은 “CISC”는 매우 초기에 나온 Processor Type으로 이때는 메모리가 비쌌습니다. 그래서 처리하는 데이터의 길이가 최대한 메모리를 아껴쓰도록 매우 가변적 이였죠. 문제는 이런 가변적인 데이터 길이 였습니다.
(그에 비해서 RISC Processor의 경우 데이터의 길이가 일정하기 때문에 멀티 프로세싱에 매우 유리 했습니다. ㅜㅜ)

“아 스케줄링 하기 너무 힘들어”

맞습니다. CISC Processor 의 경우 공간 사용량은 매우 최적화 되어있지만 데이터의 길이가 가변적이여서 스케줄링이 쉽지가 않았습니다. 그러다보니 멀티 프로세싱은 물론 Hyperthreading에서도 때로는 극악의 성능을 보이게 된거죠. 그로인해 초기의 Intel Processor의 Hyperthreading 기능은 잠시 선을 보였다 들어가 버린거죠. 실은 Intel은 이러한 CISC의 단점을 보완 하기 위해 1995년 Micro-Operation 기반의 프로세서를 시장에 선보인 이래로 개선에 개선을 거듭했습니다. 그리고 지금의 Intel Processor는 가변적인 명령어들은 다시 한번 Micro-Operation으로 가공하여 가변성으로 인한 멀티 프로세싱의 단점을 완전히 날려 버리게 되었죠.

자 그래서 지금은 어떻냐구요? 연산의 종류에 따라 다르지만 Hyperthreading을 활성화 하게 되면 약 30% 정도의 성능 향상 효과가 있다는게 일반적인 의견이구요. 기본적으로는 성능에 문제가 발생하지 않는 이상 비활성화 하지 말라는게 제 개인적인 권고 입니다.

게다가 Hyper-v는 이렇게 Hyperthreading된 LP에는 2개의 VP 동시에 할당하여 Scheduling 처리를 합니다. 즉 Scheduling에 가해지는 부하도 줄어 들게 되겠죠. 그리고 아주 효과는 약하겠지만 전반적인 성능 향상 효과와는 별개로 Hyper-v의 Scheduling 부하도 낮춰 주는 효과가 있습니다.

물론 LP와 VP의 비율이 낮다면 단일 VM 입장에서는 할당된 Virtual Processor가 고정되어 있다는 가정하에 Hyperthreading이 비활성화 되어 있는 것이 더 좋을 수 도 있겠죠. 하지만 LP 대 VP의 비율이 높다는 당연히 Hyperthreading을 활성화 하는것이 Hyper-v 전반의 성능을 위해 좋은 효과를 발휘하겠죠.

이상으로 Scheduling의 근간이 되는 개념 몇 가지를 알아봤습니다.
하지만 여전히 Scheduling에 대해서는 할말이 너무 많습니다. 기본적인 UI 설정부터 NUMA까지…
그럼 Scheduling 두 번째 이야기로 다시 찾아 뵙도록 하겠습니다.

긴 글 읽어 주셔서 감사합니다.

참고 : http://en.wikipedia.org/wiki/RISC, http://maystyle.tistory.com/559
주의 http://maystyle.tistory.com/559 는 Windows Server 2008 R2 Hyper-v 시절에 작성된 글입니다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  Hyper-V 2012 R2 기본 부터 고급 까지 1. Processor : Virtual Processor VS Logical Processor 
작성일시 : 2013.12.20 23:57 | 분류 : Cloud/Hypervisor

안녕하세요.
Windows Server 2012 R2 가 시장에 선보인 지도 벌써 반년이 지나가고 있습니다.
오늘부터 저는 여러분들과 Hyper-v 2012 R2에 대한 학습을 하고자 합니다.
오늘은 그 첫 번째 Processor 에서도 Logical Processor와 Virtual Processor의 개념에 대한 이야기를 해 보겠습니다.

1.1 Virtual Processor VS Logical Processor

Virtual Processor
간단합니다. 바로 VM이 사용하는 Processor을 의미 하죠.
VM의 작업 관리자에서 확인 할 수 있는 그 Processor 입니다.

Logical Processor
질문 : Logical Processor는 작업 관리자에서 확인 할 수 있다?
답변 : 땡! 틀렸습니다.

Logical Processor는 Hypervisor가 직접 관리하는 실제 Processor을 의미합니다.
그런대 왜? Logical Procssor 라구 불리울까요? 실은 이 Logical Processor는 Hyperthreading 까지를 포함한 Processor의 개념을 의미 하기 때문입니다.
즉 1 소켓 머신에 4 Core CPU 그리고 Hyperthreading이 활성화 되어 있다면 총 Logical Processor의 갯수는 8개가 되는 거죠. (Hyperthreading에 대해서는 다음에 다루도록 하겠습니다.) 자 그렇다면 Hyper-v의 호스트 파티션에서는 Logical Processor을 작업 관리자에서 확인 할 수 있을까요? 정답은 당연히 확인 할 수 없다 이구요 120점 짜리 정답이 되려면 작업 관리자에서는 확인이 불가능 하지만 성능 모니터에서는 확인 할 수 있다 정도가 될꺼 같습니다. 실은 Hyper-v 상에서 Partition이라고 불리는 친구들은 바로 Hyper-v에게서 CPU (Virtual Processor) 와 메모리를 할당 받은 친구들이기 때문이죠. 그리고 Hyper-v Host 역시도 Root Partition이라고 불리우는 가장 처음 시작 되는 Partition일 뿐이기 때문 입니다.
그렇기 때문에 만약 여러분이 Logical Processor가 80개인 머신에서 Hyper-v 를 활성화 했을때, Host에서 확인 가능한 Processor의 갯수가 64개 즉 Hyper-v가 VM에 줄 수 있는 최대 Processor 갯수로 줄어 버리는 거죠.

그렇기 때문에 아래 그림과 같은 일들을 실제 종종 확인 할 수 있습니다.

보시는 작업 관리자 화면은 VM의 작업 관리자에서 확인한 CPU 사용량 즉 Virtual Processor 사용량 입니다.
100%군요!!!
 image

하지만 Host에서 보면 아래와 같이 0%인 것을 볼 수 있는데 이는 당연한 결과 입니다.
결론은 둘 다 서로 각자의 Virtual Processor를 보고 있기 때문이죠.
 image

그렇기 때문에 우리는 실제 Logical Processor에 가해 지는 부하를 보기 위해 성능 카운터 중 “Hyper-v Hypervisor Logical Processor” 의 Total Run Time 및 Guest Run Time, Hypervisor Run Time 등을 확인 해야 합니다.

자 이제 둘이 서로 다르다는 것을 확인 하셨나요?

실은 Hyper-v 즉 일반적으로 Hypervisor라고 불리우는 가상화 플랫폼의 가장 큰 역활 중 하나는 바로 Logical Processor를 적절하게 VM이 소유한 Virtual Processor에 할당해 주는 것입니다.
이를 우리는 스케줄링이라고 부르고 있죠. 그리고 적절한 스케줄링을 위하여 우리의 Hyper-v 는 Partition 들과 이런 저런 정보를 교환 하게 되는데, 이렇게 정보의 교환이 원활한 Partition을 우리는 Enlighten 된 Partition 이라고 부릅니다. (Guest OS의 커널이 Hyper-v 를 인지하고 Hyper-v 운영에 필요한 정보 즉 예를 들어 스케줄링에 필요한 데이터를 전달) 물론 스케줄링 알고리즘 및 위에서 설명한 Enlighten에 대해서도 다음에 다룰 생각이니 갑자기 어려운 이야기가 나왔다고 다급해 하실 필요는 없습니다… :) 그리고 이런 정보들을 Hyper-v에 전달하기 위해 사용되는 방식이 바로 Hypercall 입니다. (정확하게는 Partition과 Hypervisor 간의 통신 인터페이스를 의미 합니다.)

이미 설명 드린 바와 같이 Host Partition이 됐건 Guest Partition이 됐건 실제로 Processor에서 동작하는 Thread들은 Partition의 Virtual Processor가 Logical Processor을 할당 받게 되면 별다른 치환 이나 변경 없이 바로 실행 되게 됩니다. 그렇기 때문에 Hyper-v 즉 Hypervisor 기반의 Partition 들이 별다른 성능 저하 없이 이론적으로 만약 Logical Processor와 Virtual Processor을 1:1로 Mapping 한 경우에는 거의 100%에 가까운 성능을 낼 수 있다고 이야기 하는 이유 입니다.

그럼 다음에 Logical Processor와 Virtual Processor의 스케줄링이라는 주제로 다시 찾아 뵙겠습니다.

감사합니다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  CSPP Virtual Machine 생성 승인을 메일을 통해 하고 싶습니다. 
작성일시 : 2013.12.16 23:27 | 분류 : Cloud/SCSM (Service Manager)

안녕하세요.

Request Virtual Machine Service Request 항목은 Reviewer의 승인(Approve Virtual Machine)이 필요합니다.
- 라이브러리 > 템플릿 > Request Virtual Machine Service Request 선택 후 속성 클릭 > 창 닫은 후 마법사에서 작업 클릭
image
CSPP 에 대한 구성이 완료는 됐지만 여러분은 항상 Service Manager 콘솔에 가야만 확인할 수 있고 승인 버튼 즉 Appove을 할 수 있을까요?

아마도 여러분은 Review 요청을 메일로 수신하고 메일로 즉시 답변하고 싶겠죠. 이번에는 Review 요청을 메일로 수신하고 다시 메일로 간단하게 Approve 하는 방법에 대해 알아보겠습니다.

Exchange Connector 구성

먼저 Exchange에 사용자 메일 박스를 하나 만들어 줍니다.
예를 들어 SCSMHelpDesk 라고 하겠습니다. 자 그렇다면 사용자 메일 박스는 SCSMHelpDesk@contoso.com 이 되겠죠… :)
그런 다음 Exchange Server Auto Discovery을 위한 DNS 설정을 추가 합니다.
예를 들어 사용하고 있는 Domain 명이 contoso.com 이라면 contoso.com에 새로운 SRV 레코드를 추가 합니다.
- Service : _autodiscover
- Protocol : _tcp
- Port Number : 443
- Host : Ex01.contoso.com (저는 임의로 Ex01을 Exchange 서버로 삼았습니다.)

자 여기까지 끝났으면 필요한 준비 작업은 끝났습니다. 이제 Exchange Connector와 연동해야 되겠죠.

먼저 Exchange Connector 3.0을 다운 받습니다.
http://www.microsoft.com/en-us/download/details.aspx?id=38791
3.0은 SCSM 2012 SP1의 Rollup 2 이상 부터 지원 됩니다.. 물론 R2도 지원 하구요.

Exchange Connector을 이용하게 되면 필요한 간단하게 Incident ID와 Message Body만으로 SCSM의 여러 Action들을 Control 할 수 있습니다. 예를 들면 만약 Incident ID가 IR1234 라면 메일 제목을 IR1234로 쓰고 메일 본문에 필요한 Activity 즉 [Closed] 또는 [Resolved]등을 기입하는 방식이죠.
image

자세한 설치 방법 설치 파일과 함께 제공되는 SM2012_EC_DepGuide을 참고 하시면 됩니다.

자 여기까지 됐으면 필요한 Activity을 SCSMHelpDesk@contoso.com 에 메일로 보내게 되면 필요한 과정을 진행하게 됩니다. 하지만 아직 Notification이 오지는 않죠.
지금부터는 Reviewer 에게 Notification을 보낸 방안을 설명하도록 하겠습니다.

Notification Channel 구성

먼저 Notification Channel을 설정해야 합니다. SCSM 관리 콘솔에서 관리를 선택한 후 알림 > 채널을 선택합니다.
image

내용을 보면 이미 “전자 메일 알림 채널”이 만들어 졌는데, 여기에 우리는 메일 발신을 위한 SMTP만 등록해주면 되죠. 물론 전자 메일 주소 반환 항목에는 이미 설정해 놓은 SCSMHelpDesk@contoso.com을 등록 합니다.
image

(여담으로 이전 글에서는 SCVMM에 대한 이해와 함께 Private Cloud 운영에 대한 이해가 필요 했는데, 이번에는 DNS에서 부터 Exchange 그리고 SMTP 설정까지를 담고 있군요… ㅜㅜ 쉽지 않습니다.)

Notification Template 작성

자 채널까지 만들어 졌으니 이젠 Notification을 템플릿을 작성해야 겠죠?
먼저 알림>템플릿을 클릭 합니다.
image

우측의 작업 창에서 “전자 메일 템플릿 만들기”을 클릭 합니다.
image

이때 대상 클래스는 검토 작업으로 해주셔야 합니다.
아래의 찾아 보기를 클릭한 후 검토 작업을 선택 해주시면 되겠죠… :) 영어로는 Review Activity 가 되겠습니다.
image image

특히 템플릿 디자인에서 삽입 버튼을 누르면 메일 제목 및 본문에 다양한 필요한 내용을 넣어 줄 수 있습니다.
예를 들어 아래와 같이 작업 항목에 ID를 선택한다면
image
아래와 같이 자동으로 필요한 내용들이 삽입되게 되는 거죠.
image

자 이제 필요한 템플릿을 만들었습니다.
(물론 마지막에 해당 템플릿에 대한 Exchange Connector을 이용한 관리를 위해 추가적인 설정이 필요합니다만… 마지막에 다루기로 하고…)
이제는 Review 요청이 오면 바로 메일이 오도록 설정해 줘야 합니다. 보통은 구독이라고 하죠.

Workflow을 통한 메일 보내기 설정 하기

구독에 대한 설정 역시 관리 > 알림 > 구독 부분에서 할 수 있습니다.
역시 관리 > 워크플로 > 구성 에서 “작업 이벤트 워크플로 구성”을 선택 하고 우측 작업 창의 “워크플로 규칙 구성”을 클릭 합니다.
image

클래스 선택에서 검토 작업을 선택 합니다.
image 

이렇게 하여 워크플로 구성 창이 뜨게 되면 새로운 워크플로를 추가 하면 됩니다.
이때 이벤트 확인란은 “개체를 업데이트하는 경우”을 선택합니다.
image

당연히 작업의 상태가 진행 중일 때 받으면 않되겠죠.
image

마지막으로 알릴 사람 선택에 가면 이전에 만들어 놓았던 메시지 템플릿을 확인할 수 있습니다. 당연히 알림 사용 클릭 후 추가 해야겠죠… : )

메일 본문에 승인 버튼 넣기

자 드디어 마지막 작업 입니다. 바로 메일 본문에 승인 버튼을 넣는 건데요. 이미 설명 드린 바와 같이 SCSMHelpDesk@contoso.com 에게 메일 제목은 “WorkItem ID” 메일 본문은 승인 하는 경우 “[Approved]” 거절하는 경우 “[Rejected]” 라는 내용을 삽입하여 메일을 쓰게 되면 간단한 승인 또는 거절이 가능한데요. 이 부분을 그때 그때 마다 메일을 받는 담당자가 직접 SCSMHelpDesk@contoso.com 에 내용을 적어서 보내는 건 좀 그렇죠?
그래서 간단한 꼼수를 알려 드립니다.

이미 우리는 메시지 템플릿을 만들어 놨습니다.
이제는 본문에 메일 보내기에 대한 하이퍼링크만 달아 주면 간단하게 해결이 됩니다.
제 경우는 다음과 같이 하면 되겠죠?

image

<a href="mailto:SCSMHelpDesk@contoso.com?subject=[<insert the work item ID here>]&body=[Approved]">Approved</a>
<br/>
<a href="mailto:SCSMHelpDesk@contoso.com?subject=[<insert the work item ID here>]&body=[Rejected]">Rejected</a>

이렇게 해 놓으면 아래와 같이 Approved 또는 Rejected 에 대한 링크가 뜨고 해당 링크를 클릭하면 바로 메일이 하나 생성이 됩니다. 여러분은 그저… Send 버튼만 누르시면 모든일이 완료 되게 되죠… :)
image

여기까지 따라온 당신이라면 다른 주제들에 대해서도 최고가 되리라 확인 해 봅니다.
그럼 다음에 다른 주제로 다시 찾아 뵙겠습니다.

출처 : http://blogs.technet.com/b/servicemanager/archive/2011/02/08/tricky-way-to-handle-review-activity-approvals-with-the-exchange-connector.aspx

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  CSPP 소개 - Priavate Cloud 손쉽게 만들어 봅시다. 
작성일시 : 2013.12.16 21:30 | 분류 : Cloud/SCSM (Service Manager)

여러분의 시스템에 System Center Service Manager 가 인스톨 되어 있다면 CSPP을 추가로 인스톨 하는 것 만으로 Private Cloud 시스템을 구축 할 수 있습니다.

특히 CSPP의 경우 Service Manager의 Cloud 관리를 위한 결제 프로세스와 같은 Workflow 및 여러 데이터 센터 작업에 대한 Orchestrator 의 Runbook을 자동으로 생성해주기 때문에 실제 구현 시 단순 Installation 작업 및 몇몇 Configuration 작업 만으로 자신만의 Private Cloud 데이터를 만들 수 있습니다.
(특히 Microsoft에서 미리 정의 해 놓은 Private Cloud의 여러 Workflow 를 바로 쓸 수 있다는 장점이 있죠.)

CSPP에 다가가기 위한 Required Knowleadge 에 대해 알아보겠습니다.

Cloud Service는 실제로는 VMM의 리소스를 의미 합니다. 우리는 VMM에서 이미 구현 되어 있는 여러 가지 서비스 특히 VM Template과 같은 형태의 서비스를 사용하기 위하여 먼저 해당 Cloud Service을 구독 즉 Subsciption 하게 되는데, 이는 다음의 문서를 통해 확인 할 수 있습니다.
Cloud Services Terminology : http://technet.microsoft.com/en-us/library/hh872874.aspx
About Cloud Services User Roles : http://technet.microsoft.com/en-us/library/hh872827.aspx

VMM을 통해 구현된 Cloud는 실제로는 추상화된 Infrastructer 와 아주 잘 Provisioning 된 서비스의 리스트 (VM Template을 포함)로 볼 수 있는데요. 이는 그 상위 레벨에서 사용자는 Tenant 단위로 관리되게 됩니다. 먼저 사용자는 Tenant 를 요청하게 되고, 이후 생성된 Tenant에 필요한 Cloud 리소스들을 Subscription 즉 사용할 수 있도록 할당해줍니다. 다시 말해 Tenant 는 Cloud 관리자에게 VMM을 통해 이미 만들어진 Cloud 및 Cloud을 이루고 있는 리소스에 대한 구독 즉 Subscription을 요청하고 이러한 기본적인 작업이 완료된 이후 우리는 VM의 생성 및 Update을 간단한 서비스 요청으로써 제공 받을 수 있습니다.
Process Workflows : http://technet.microsoft.com/en-us/library/hh872838.aspx

자 시작하기 전에 Virtual Machine Manager의 리소스에 대한 이해가 필요한데요. 아래의 사항에 대해서만 이해 하시면 됩니다.
About Virtual Machine Manager Resources : http://technet.microsoft.com/en-us/library/hh872828.aspx

설치가 완료된 이후에는 몇 가지 수동으로 진행해야 하는 작업들이 있습니다. 먼저 Connector을 만들어 줘야 합니다. 특히 기본적으로 VMM, Orchestrator OM 그리고 AD에 대한 Connector가 필요하며 아래의 문서를 참조 하시면 됩니다.
Create Connectors : http://technet.microsoft.com/en-us/library/hh872851.aspx
위의 문서는 여타 System Center 제품과의 연동은 정리되어 있습니다. 다만 하나 ”아! AD는 빠져 있군요.”
아래와 같이 System Center 및 AD와의 연동을 마무리 지었습니다.
image

여러 가지 설정을 해놓고 실제 VMM의 리소스 내역을 봤더니… 음… 아무 내용도 없군요.
image

자 이제 Conntor 설정은 모두 끝났고 VMM Resource에 대한 설정을 진행 해야 합니다.
Configure Virtual Machine Manager Resources : http://technet.microsoft.com/en-us/library/hh872818.aspx

위의 설정까지 완료가 됐다면 Service Manager에서 어떻게 Cloud 서비스를 다룰지를 설정해 줄 필요가 있습니다.
그 중 가장 우선 진행 해야 하는 것이 Tenant ID 및 Cloud Resources Subscription ID 대한 Prefix을 정의해 주는 거겠죠.
Configure General Properties : http://technet.microsoft.com/en-us/library/hh872839.aspx
그 외에 비용과 관련된 부분 설정이 필요 합니다. (VM별 비용 설정 및 Cost Center / 부서별 비용 코드 설정)
Configure Cost Properties : http://technet.microsoft.com/en-us/library/hh872830.aspx
Create Cost Center : http://technet.microsoft.com/en-us/library/hh872853.aspx

자 이제 CSPP의 Installation 만으로 간단한 (나름… 간단한…) Private Cloud 구축에 대해 알아봤습니다.
관리에 대한 부분은 아래의 URL을 참고하시면 됩니다.
CSPP Administration : http://technet.microsoft.com/en-us/library/hh872820.aspx

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
 Prev   1   Next 

티스토리 툴바