자습서: vRealize Automation에서 vSphere 리소스 온보딩 및 관리

최근에 새 클라우드 계정을 추가한 클라우드 관리자가 Cloud Assembly 및 Service Broker를 사용하여 일부 vCenter Server 워크로드에 대한 관리를 시작하려고 합니다. 이 자습서는 온보딩 프로세스와 기존 vSphere 워크로드에 대한 몇 가지 관리 옵션을 설정하는 방법을 안내합니다.

샘플 관리 작업에는 프로젝트에 리소스를 추가하고, Service Broker에서 승인 정책을 생성 및 적용하고, 리소스에 대해 몇 가지 2일차 작업을 실행하여 수명 주기 관리 도구를 시연하고 승인 정책을 트리거하는 작업이 포함됩니다.

이 자습서에서는 Cloud Assembly가 비교적 생소할 수 있지만 새 vSphere 클라우드 계정을 구성했다고 가정합니다. 클라우드 계정을 추가하면 Cloud Assembly가 vSphere 인스턴스에서 현재 관리되지 않는 리소스를 검색합니다.

우선 수행할 작업

새 vCenter Server 계정을 추가합니다. 추가적인 지침은 vRealize Automation에서 vCenter 클라우드 계정 생성 항목을 참조하십시오.
사용자 계정에 적어도 Cloud Assembly 관리자 및 Service Broker 관리자 서비스 역할이 있는지 확인합니다. vRealize Automation 사용자 역할이란?의 내용을 참조하십시오.
사용자 관점에서 승인 정책을 올바르게 테스트하려면 다음 사용자 역할만 있는 사용자 계정이 있는지 확인합니다. 이 자습서에서 사용자 이름은 Sylvia입니다.
- 조직 멤버
- Cloud Assembly 사용자
- Service Broker 사용자
사용자 역할에 대한 자세한 내용은 vRealize Automation 사용자 역할이란? 항목을 참조하십시오.

1단계: Cloud Assembly가 리소스를 검색했는지 확인

vCenter Server 계정을 추가하면 Cloud Assembly가 vCenter Server 인스턴스에서 리소스를 검색합니다. 관리를 시작하려는 시스템을 온보딩할 수 있는지 확인할 수 있습니다.

Cloud Assembly에서 리소스 > 리소스 > 가상 시스템을 선택합니다.
그리드에서 원본 및 계정/지역을 검토합니다.
[검색됨] 원본 유형은 시스템이 vRealize Automation에서 배포되었거나 이미 온보딩된 시스템이 아니라 vSphere 인스턴스에서 검색되었음을 나타냅니다.

이 예에서 [계정/지역]은 vCenter Account / wld01-DC입니다.

2단계: 대상 프로젝트 생성

온보딩된 시스템을 할당할 수 있는 프로젝트를 생성합니다. 리소스를 관리하려면 리소스가 원래 배포된 소스 클라우드 영역이 포함된 프로젝트의 일부여야 합니다.

이 자습서를 테스트하려면 관리자가 아닌 다른 사용자가 있어야 합니다. 이 단계에서 관리자는 Sylvia를 프로젝트 멤버로 추가합니다.

프로젝트에 대한 자세한 내용은 Cloud Assembly 프로젝트 추가 및 관리 항목을 참조하십시오.

Cloud Assembly에서 인프라 > 프로젝트 > .를 선택합니다.
[프로젝트] 페이지에서 새 프로젝트를 클릭합니다.
프로젝트 이름을 입력합니다.
이 자습서에서 프로젝트 이름은 Onboarding Project입니다.
사용자 탭을 클릭합니다.
1. 사용자 추가를 클릭하고 하나 이상의 사용자를 최소한 프로젝트 멤버로 추가합니다.
  이 자습서에서는 Sylvia를 추가합니다.
2. 추가를 클릭합니다.
프로비저닝을 클릭합니다.
1. 영역 추가를 클릭합니다.
2. 클라우드 영역을 클릭합니다.
3. 1단계에서 식별한 계정/지역을 선택합니다.
  이 자습서에서 샘플 값은 vCenter Account/wld01-DC입니다.
4. 추가를 클릭합니다.
생성을 클릭합니다.

3단계: 온보딩 계획 생성 및 실행

클라우드 관리자가 2일차 작업으로 거버넌스를 적용하고 리소스를 관리할 수 있도록 vSphere 인스턴스에서 검색된 시스템을 온보딩합니다.

온보딩 계획에 대한 자세한 내용은 Cloud Assembly의 온보딩 계획이란? 항목을 참조하십시오.

Cloud Assembly에서 인프라 > 온보딩을 선택한 다음 새 온보딩 계획을 클릭합니다.

온보딩 정보를 입력합니다.

설정	샘플 값
계획 이름	wld01-DC 온보딩 계획
클라우드 계정	vCenter 계정
기본 프로젝트	온보딩 프로젝트

생성을 클릭합니다.
온보딩할 시스템을 추가합니다.
다음 단계를 모두 완료할 때까지 온보딩 계획을 실행하지 마십시오.
1. 시스템을 클릭한 후 시스템 추가를 클릭합니다.
2. 계획에 포함하려는 시스템을 선택하고 확인을 클릭합니다.
  이 자습서에서는 두 개의 시스템만 선택됩니다.
3. [배포 생성] 대화상자에서 각 시스템에 대한 계획 배포 생성을 선택하고 생성을 클릭합니다.
  시스템을 개별 배포로 사용하여 개별 리소스로 관리하려는 경우 이 옵션을 선택합니다.
4. 선택한 시스템이 목록에 추가됩니다.
배포의 이름을 변경합니다.
1. 온보딩 페이지에서 배포 클릭합니다.
2. 생성된 배포 이름을 변경하려면 배포를 선택하고 이름 변경을 클릭합니다.
3. 새 이름을 입력하고 저장을 클릭합니다.
  예를 들어 Onboarded machine 1이라고 입력합니다.
4. 필요에 따라 반복합니다.
배포에 소유자를 할당합니다.
소유자를 할당하지 않으면 소유자가 됩니다. 소유자는 대상 프로젝트의 멤버여야 합니다.
이 자습서에서는 모든 배포를 동일한 소유자에게 할당합니다. 필요한 경우 다른 배포를 다른 소유자에게 할당할 수 있습니다.
1. 모든 배포를 선택하고 소유자 편집을 클릭합니다.
2. 소유자를 선택하고 저장을 클릭합니다.
그리드에서 배포 이름 및 소유자 변경 내용을 검토합니다.
실행을 클릭합니다.
온보딩 계획을 실행한 후에는 이름을 수정하거나 소유자를 할당할 수 없습니다. 계획에 시스템을 더 추가하는 경우 이름 또는 소유자를 수정할 수 있습니다.
배포로 온보딩한 리소스를 검토합니다.
1. 리소스 > 배포를 선택합니다.
2. 배포를 찾으려는 경우 배포 이름, 프로젝트 또는 소유자로 검색할 수 있습니다.

시스템을 vRealize Automation로 가져왔으므로 관리를 시작할 수 있습니다.

4단계: 배포 크기 조정

이 단계를 클라우드 관리자로 수행하고 2일차 작업의 작동 방식을 숙지합니다. 배포에 대해 수행할 수 있는 변경을 2일차 작업이라고 합니다. 2일차 작업의 사용은 리소스 관리의 첫 번째 단계입니다.

이 자습서에서는 시스템의 CPU 수가 너무 많다고 판단하고 사용된 CPU를 줄이려고 합니다. 이 절차에서는 전원이 켜진 vSphere 시스템에서 크기 조정 작업을 실행 중이라고 가정합니다. 또한 사용자가 이 작업을 실행하는 것을 금지하는 2일차 정책이 없다고 가정합니다.

사용 가능한 작업은 리소스 유형, 리소스 상태 및 2일차 정책에 따라 다릅니다. 2일차 작업에 대한 자세한 내용은 Cloud Assembly 배포에서 실행할 수 있는 작업 항목을 참조하십시오.

Cloud Assembly에서 리소 > 배포를 선택한 다음 온보딩된 배포를 찾습니다.
검색 또는 필터 옵션을 사용할 수 있습니다.
왼쪽의 화살표를 사용하여 배포를 확장한 다음 시스템 이름에 대한 세로 줄임표를 클릭하고 크기 조정을 클릭합니다.
크기 조정 대화 상자에서 CPU 수를 4로 줄이고 제출을 클릭합니다.
제안된 값은 하나의 예로, CPU 수를 환경에서 작동하는 값으로 변경합니다.
작업은 시스템에서 실행됩니다.
CPU 수가 변경되었는지 확인하려면 배포를 열고 시스템의 cpuCount 사용자 지정 속성을 확인합니다.
vCenter Server 수를 확인할 수도 있습니다.

5단계: 승인 정책 적용

클라우드 관리자는 vRealize Automation에서 거버넌스를 적용하여 사용자가 수행할 수 있는 작업을 제한하거나 사용자가 작업을 수행하기 전에 승인을 받도록 요구할 수 있습니다. 이 자습서에서는 사용자가 클라우드 관리자의 승인이나 다른 관리자의 승인 없이 시스템을 치명적으로 재구성할 수 없도록 크기 조정 작업에 승인 정책을 적용하는 방법을 보여 줍니다.

정책은 Service Broker에서 생성됩니다. 그러나 정책은 Cloud Assembly 및 Service Broker의 관련 요청에 적용됩니다.

승인자는 Service Broker의 승인 요청에 응답해야 합니다.

Service Broker에서 컨텐츠 및 정책 > 정책 > 정의를 선택하고 새 정책을 클릭합니다.
승인 정책을 클릭합니다.

승인 정책을 구성합니다.
다음 표에 설명된 값이 포함된 승인 정책의 스크린샷.

다음 표에는 정책 생성 방법을 보여 주는 샘플 값이 포함되어 있습니다.

설정	샘플 값
이름	크기 조정 승인 정책
범위	프로젝트를 선택한 다음 `온보딩 프로젝트`를 선택합니다. 프로젝트의 멤버인 사용자가 [크기 조정] 2일차 작업을 실행할 때 승인 정책이 트리거됩니다.
승인 유형	사용자 기반 이 값을 사용하면 승인자의 이름을 지정할 수 있습니다.
승인자 모드	임의 승인자가 여러 명 있는 경우 승인 요청을 하나 이상의 승인자가 확인할 수 있습니다.
승인자	자신을 승인자로 추가합니다.
자동 만료 결정	거부 검토되지 않은 요청을 거부하면 시스템을 사용할 수 없게 되거나 리소스가 초과될 위험이 줄어듭니다.
자동 만료 트리거	1
작업	승인 정책을 트리거하는 크기 조정 작업을 선택합니다. 검색에 `machine.resize`를 입력합니다. 검색 결과 드롭다운 목록에서 여러 항목 선택을 클릭합니다. `Cloud.vSphere.Machine.Resize`를 선택합니다. vSphere 기반의 이 자습서에서는 vSphere.Machine 작업을 선택합니다. 작업 정책을 다른 리소스 유형에 적용하려는 경우 다른 Machine.Resize 작업을 추가할 수 있습니다.

6단계: 사용자로 크기 조정 요청 요청

이 단계에서는 조직 멤버 및 Service Broker 사용자로 Service Broker에 로그인하고 크기 조정 2일차 요청을 실행합니다. 이 요청은 승인 요청을 생성합니다. 사용자가 Cloud Assembly에서 동일한 단계를 수행할 수도 있습니다.

이후 단계에서는 5단계에서 승인자로 할당한 사용자로 로그인하고 요청을 승인합니다.

사용자로 Service Broker에 로그인합니다.
이 자습서에서 사용자는 Sylvia입니다.
리소스 > 배포를 선택하고 Onboarded machine 1을 찾습니다.
이 배포는 4단계에서 시스템에 대해 크기 조정 작업을 실행하여 CPU 수를 8에서 4로 변경한 배포입니다. 다른 값을 사용한 경우 테스트하려는 방식으로 시스템을 수정합니다.
시스템에서 크기 조정 작업을 실행하여 CPU 수를 6으로 늘립니다.
요청이 승인 대기 중입니다.
보류 중 상태를 보려면 그리드의 정보 아이콘 위로 마우스를 가져가거나 배포를 열고 기록 탭을 검토합니다.
Sylvia가 사용자로서 요청한 변경 내용은 승인될 때까지 진행되지 않습니다.
사용자로 Service Broker에서 로그아웃합니다.
7단계에서는 할당된 승인자로 로그인하고 요청에 응답합니다.

7단계: 승인 요청에 응답

요청에 승인이 필요하고 사용자가 승인자인 경우 이메일 메시지가 수신됩니다. 이 자습서에서는 메시지를 기다리지 않습니다. 대신 이 프로세스는 Service Broker 받은 편지함 탭을 사용하여 승인 요청에 직접 응답하도록 안내합니다.

5단계에서 승인자로 할당된 사용자로 Service Broker에 로그인합니다.
이 자습서에서 승인자는 Fritz입니다.
리소스 > 배포를 선택하고 Onboarded machine 1을 찾습니다.
상태는 Sylvia의 경우와 동일하게 그리드가 보입니다.
받은 편지함 > 승인을 선택합니다.
보류 중인 승인 요청이 있습니다.
요청 세부 정보를 보려면 배포 이름을 클릭합니다.
승인을 클릭하고 설명을 제공하고(필요한 경우) 승인 클릭합니다.
배포 페이지로 돌아가 Sylvia의 크기 조정 작업이 현재 진행 중인지 확인합니다.
크기 조정 작업이 완료되면 배포 세부 정보 및 vSphere Client에서 CPU 수를 확인할 수 있습니다.

이 자습서에서는 리소스의 수명 주기 관리를 시작할 수 있도록 시스템을 vRealize Automation로 가져오는 프로세스를 안내했습니다.