[study38] 기본 셋팅 이후의 추가셋팅 03/11(3)

Resource Pool

 

 

물리 서버 자원을 팀별·업무별로 구획해서 “누가 어느 정도 우선순위로 쓸지” 정하는 틀

 

각 호스트나 DRS 클러스터에는 보이지 않는 루트 리소스 풀이 하나 있고, 그 아래에 사용자가 자식 리소스 풀을 여러 개 만들 수 있음. 

계층 구조로 자원을 나눌 수 있음

 

 

리소스 풀에서 제일 중요한 설정은 4개입니다

Shares, Reservation, Limit, Expandable Reservation

 

[ Share ] 자원 경쟁이 생겼을 때, 누구를 더 우선할지 정하는 비율

Low, Normal, High가 대략 1:2:4 비율이고, 형제 리소스 풀끼리 상대적으로 비교됩니다.

 

[ Reservation ] 은 최소 보장량

 

[ Limit ] 은 최대 사용 한도. 보통은 Unlimited로 둡니다

 

[ Expandable Reservation ]은 기본값이 켜져 있는데, 자식 풀이 자기 예약량만으로 부족할 때 부모 풀 쪽의 남는 예약 자원을 빌려오게 해주는 옵션

 

왜 쓰냐면, 팀별로 자원을 나눠주고 관리 권한도 위임하기 좋기 때문입니다. 예를 들어 마케팅팀 VM 3대, QA팀 VM 2대가 있는데 QA가 더 무거운 작업을 돌린다면 QA용 리소스 풀을 따로 만들고 Shares를 높게 주면 됩니다. 그러면 QA가 자원 경쟁 시 우선권을 갖고, QA가 안 쓰는 시간에는 마케팅이 남는 자원을 사용할 수 있습니다. 또 DRS 클러스터에서는 자원 관리가 개별 호스트가 아니라 클러스터 전체 기준으로 이루어지므로, 하드웨어 구성이 조금 바뀌어도 리소스 배분 정책을 크게 안 바꿔도 되는 장점이 있습니다.

 

리소스 풀 생성은 호스트, 기존 리소스 풀, DRS 클러스터 아래에서 만들 수 있습니다.

다만 호스트가 이미 클러스터에 들어가 있으면 그 호스트 바로 아래에는 리소스 풀을 못 만들고,

대신 DRS가 켜진 클러스터 아래에 만들어야 합니다. 생성할 때 이름을 정하고 CPU/메모리별로 Shares, Reservation, Limit 등을 넣습니다. 또 Scalable Shares 옵션을 켜면 VM이 늘거나 줄 때 shares가 부모 레벨에서 동적으로 스케일되도록 할 수 있습니다.

 

 

VM을 리소스 풀에 넣는 것도 중요합니다. VM 생성 시 지정할 수도 있고, 기존 VM도 Migrate로 다른 리소스 풀로 옮길 수 있습니다. 옮길 때 VM의 Reservation과 Limit은 그대로 유지되고, Shares가 High/Medium/Low 같은 상대값이면 새 리소스 풀 기준으로 다시 계산됩니다.

 

만약 VM에 Custom Shares를 줬다면 그 숫자는 유지됩니다. 그래서 VM을 다른 풀로 이동하면, 새 풀 안에서 비율이 너무 커지거나 작아질 수 있으니 shares를 다시 조정해야 할 수도 있습니다. 그리고 전원이 켜진 VM을 옮길 때는 목적지 리소스 풀이 그 VM의 예약량을 보장할 수 있어야 해서, 자원이 부족하면 이동이 실패합니다.

리소스 풀 삭제는 인벤토리에서 지우는 방식이고, VM 제거는 다른 리소스 풀로 옮기거나 삭제하면 됩니다. VM 하나가 빠지면 남은 VM들이 같은 총 자원을 더 적은 수로 나눠 가지게 되므로, 각 VM이 가져가는 몫이 커질 수 있습니다.

 

[ Admission Control ]

VM 전원을 켜거나 자식 리소스 풀을 만들 때, 실제로 예약량을 감당할 수 있는지 검사하는 절차

 

Reservation Type은 크게 두 가지입니다.

Fixed 는 현재 선택한 리소스 풀 내부에 남는 예약 자원이 충분해야만 허용됩니다. 부족하면 바로 실패합니다.
Expandable 은 현재 풀에 부족해도 부모 풀, 조상 풀 쪽으로 올라가며 남는 예약 자원을 빌릴 수 있는지 확인합니다. 기본값이라 더 유연하지만, 그만큼 자식 풀이 부모 자원을 예상보다 많이 가져갈 수 있어서 엄격한 격리성은 약해집니다