[22.07.27 업뎃] Azure maintenance control (유지 보수 관리) [계획된 유지 보수 관리를 어떻게 내가 결정할 수 있어?]

https://docs.microsoft.com/en-us/azure/virtual-machines/updates-maintenance-overview

 

 

내 오랜 의문 중 하나는 다음과 같았다.

Azure에게 사용자에게 계획된 유지 관리를 시작할 수 있는 시간을 제공한다고 하는데.. (최대 35일)

이게 말이 되나?

보통 서버를 다른 사람들과 같이 공유해서 쓸텐데, 이게 어떻게 가능하지?

내가 재부팅하면 다른 사람들의 서버도 꺼질거아냐?

라고 생각을 했는데!

 

-> isolated VMs 혹은 Azure dedicated hosts만 가능한거였다. ㅎㅎㅎ...

이러면 당연하지. 그 서버를 나만 쓰는거니까...

 

---

Azure 가상 머신의 가용성이 영향을 받을 수 있는 다운 타임 시나리오는 3가지가 있다.

 

1) 계획되지 않은 하드웨어 유지 관리

Azure 인프라에서 하드웨어나 플랫폼에 문제가 발생할 것으로 예측(Azure ML 알고리즘)될 때, 이벤트를 일으켜서 물리 서버에서 실행중인 가상 머신이 영향을 받지 않거나 적게 받도록 한다.

"Live Migration" 기술을 사용해서, 서비스를 계속 제공하면서 정상 운영 중인 물리 서버로 이관시킨다.

(RAM, 열린 파일, 네트워크 연결 유지)

 

2) 계획된 유지 관리

가상 머신을 제공하는 인프라의 안정성과 보안, 성능을 향상시키기 위해 MS가 수행하는 정기적인 업데이트와 보안 패치 작업을 말한다. (당연히 하이퍼바이저의 업데이트/패치를 말하겠지.)

 

여기서 2가지로 나뉜다.

- 재부팅이 필요하지 않은 경우 :

호스트를 업데이트하는 동안 VM이 10-30초 일시 중지되거나 이미 업데이트된 호스트로 live migration 된다.

-> Fault Domain에 적용

참고) 대다수의 VM에서는 일시 중지 되는동안 RAM에 담긴 내용이 보존되지만, G,L,M,N,H 시리즈에서는 보존되지 않는다. (22.7.27 현재)

 

- 재부팅이 필요한 경우 :

미리 Alert이 제공되고 사용자가 편리한 시간에 유지 관리를 직접 시작할 수 있도록 최대 35일의 시간을 제공한다.

-> Update Domain에 적용

 

의문) 왜 migration을 안시키고 재부팅을 시키는걸까? 라고 생각했는데

위에서 재부팅이 필요한 경우는 isolated VM이나 dedicated host라고 했잖아? 그러면 어디로 migration 시킬 곳이 없으니까

당연히 재부팅을 해야하는거지... 그러면 해결!

아마 Managed SQL Server도 dedicated host라서 유지 보수에 재부팅이 필요했던 것 같다.

 

3) 예측하지 못한 다운타임

Azure 인프라에 예상치 못한 문제가 생기면 Azure 가상 머신은 자동으로 동일한 DC의 물리 서버로 마이그레이션 된다. 복구 과정에서 재부팅이 일어날 수도 있고 임시 드라이브가 손실될 수도 있다. 이 경우를 예방하려면 AVset, AVzone, Region Pairs에 Site Recovery를 구성해야 한다.