Нюансы обновлений Azure Stack

В одной из предыдущих записей я упоминал ECE (Enterprise Cloud Engine).

 

Данный сервис, на текущий момент, крутиться на ERSC виртуальных машинах, которые имеют относительно небольшой объём ОЗУ (~8Gb) и vCPU.

 

Для тех кто не знает - поясняю:
ERSC решают несколько задач:

• это и Privilege Endpoint (PEP); 
• и обработка ECE,  который передаёт информацию на портал и с него в недра Azure Stack и т.д.;

 

В чём, собственно, соль.

 

Каждая открытая сессия портала и запросы с него или сессия на PEP обрабатываются ERSC. Все эти активности выедают и без того небольшой объём памяти и процессорной мощности, выделенных на ВМ.

 

Насколько мне известно, при запуске из экземпляра консоли администратора процесса обновлений, сессия, открытая на ECE  для этого экземпляра, также кэширует содержимое обновления. Это может быть несколько гигабайт.

 

Проблема в том, что при таком раскладе, работа ECE может нарушаться, что приводит к проблемам при обновлении.


Вывод и рекомендация от производителя: при проведении процесса обновлений необходимо выполнять выход из всех открытых сессий к интерфейсам администратора.


Ниже вы найдёте рекомендации для OpsMgr по перенастройки мониторов.
Кстати, наличие OpsMgr тоже может приводить к проблемам с обновлениями, т.к. он будет постоянно дёргать доступные ему интерфейсы с высокой  частотой.


Настройте следующие мониторы на момент обновления, как описано ниже:


Microsoft Azure Stack Update Run 

• Availability 
  • Microsoft Azure Stack Update Run State Monitor 

Microsoft Azure Stack Update 

• Availability 
  • Microsoft Azure Stack Update State Monitor 

• Discovered Type: Microsoft Azure Stack Update Run 
  • Microsoft Azure Stack Update Run Discovery 

 Interval override value to 3600. 

 
Продуктовая команда, по слухам, собирается доработать код ECE, чтобы снизить кол-во таких проблем в будущем.