Оновлення хмари CloudStack, поки інстанси орендарів працюють

Коли виходить бюлетень безпеки для платформи, на якій працюють чужі сервери, є два погані інстинкти. Один: чекати, бо торкатися хмари здається ризикованішим за вразливість. Інший: оновити все одразу і сподіватися. Apache CloudStack винагороджує третій підхід: зрозуміти його шари, оновлювати їх у правильному порядку і дати доказам вирішити, які кроки насправді торкаються орендарів.

Хмара є кількома речами для оновлення, а не однією

Розгортання CloudStack є стеком компонентів з різними радіусами ураження:

• Сервери керування та їхня база даних. Площина керування: портал, API, оркестрація. Поки вона недоступна, користувачі не можуть створювати чи змінювати ресурси, але запущені інстанси від неї не залежать.
• Агенти на кожному хості KVM. Вони з’єднують гіпервізори з сервером керування. Перезапуск агента не зупиняє інстанси, що вже працюють на цьому хості.
• Системні VM. Secondary storage VM обробляє шаблони і snapshots, console proxy обслуговує браузерні консолі. Їх перезапуск на мить перериває ці функції, а не навантаження орендарів.
• Віртуальні маршрутизатори. Вони стоять у шляху даних мереж орендарів, надаючи DHCP, DNS, NAT, firewall і балансування навантаження. Перезапуск одного з них на мить перериває сервіси тієї мережі.

Порядок роботи випливає з цього списку: спершу частини, яких орендарі ніколи не відчувають, частини, які вони можуть відчути, наприкінці, і ці останні лише тоді, коли є реальна причина.

Крок перший: прочитайте бюлетень на тлі власної конфігурації

Більшість бюлетенів стосуються конкретної функції, часто необов’язкової. Перш ніж планувати вікно, з’ясуйте, чи увімкнена уражена функція у вашій хмарі. Глобальні налаштування видно через API, наприклад за допомогою CloudMonkey:

cmk list configurations name=<setting from the advisory>
cmk list zones
cmk list hosts type=Routing

Це каже вам, наскільки термінове оновлення саме для вас, і дає запис стану до зміни.

Крок другий: зробіть резервну копію того, що знадобиться для повернення

Перед будь-якими змінами пакетів зробіть консистентний dump баз даних CloudStack і скопіюйте файли конфігурації сервера керування за межі машини:

mysqldump --single-transaction --routines --triggers cloud > cloud-before-update.sql
mysqldump --single-transaction cloud_usage > cloud_usage-before-update.sql
tar czf cloudstack-etc-before-update.tgz /etc/cloudstack

Тримайте dumps поза сервером керування.

Крок третій: сервери керування

Після оновлення пакетів management перевірте дві речі. І перевіряйте дві речі після будь-якого оновлення. По-перше, що сервіс увімкнений на запуск під час завантаження, як ви й задумували. По-друге, що він справді завершив запуск, а не просто процес існує:

systemctl is-enabled cloudstack-management
systemctl status cloudstack-management
journalctl -u cloudstack-management -f
cmk list capabilities

Дочекайтеся, поки журнал покаже завершення запуску і API відповість, перш ніж іти далі. Якщо у вас кілька серверів керування за балансувальником, оновлюйте їх по одному, щоб API залишався доступним увесь час.

Крок четвертий: агенти, по одному хосту, з гальмом

Оновіть пакет агента на одному хості KVM, перезапустіть агент і зачекайте, поки сервер керування знову побачить цей хост як Up, перш ніж переходити до наступного. Напишіть скрипт, якщо хостів багато, але дайте скрипту гальмо:

for h in $(cat kvm-hosts.txt); do
  ssh "$h" 'dnf -y update cloudstack-agent && systemctl restart cloudstack-agent' || exit 1
  until cmk list hosts name="$h" filter=state | grep -q Up; do sleep 10; done
done

Якщо якийсь хост не оновлюється або не перепідключається, цикл зупиняється саме там, з одним хостом для розслідування замість цілої хмари. Інстанси весь цей час працюють на своїх хостах, бо агент не стоїть у їхньому шляху.

Крок п’ятий: системні VM, потім маршрутизатори за доказами

Системні VM несуть скрипти і пакети з сервера керування. Після оновлення перезапустіть або оновіть їх через API, щоб вони підхопили новий код, потім підтвердьте, що вони повертаються у стан Running і підключені:

cmk list systemvms

Віртуальні маршрутизатори заслуговують більшої уваги, бо вони стоять у трафіку орендарів. Платформа може позначити маршрутизатори як такі, що потребують оновлення, але цей прапорець може бути встановлений і тоді, коли код усередині них суттєво не змінився. Порівняйте скрипти, які маршрутизатор отримав би після оновлення, з тими, що він уже виконує. Якщо код маршрутизатора не змінився, не чіпайте його і позбавте орендарів перерви. Якщо змінився, заплануйте перезапуски маршрутизаторів для кожної мережі окремо, повідомте відповідних орендарів і робіть це по одному.

cmk list routers requiresupgrade=true

Крок шостий: доведіть кінцевий стан

Виконайте ті самі перевірки, що й на першому кроці, і порівняйте: кожен хост Up, кожна системна VM Running, кожен маршрутизатор у своєму очікуваному стані, налаштування з бюлетеня там, де ви хочете, і тестовий інстанс створений, запущений і знищений через API. Потім занотуйте час від першої зміни до «зеленого», який каже вам, яким має бути наступне вікно.

Як це робимо ми

Ми будуємо хмари Apache CloudStack для кожного клієнта окремо, за специфікацією клієнта, на хостах KVM на обладнанні HPE і Dell з enterprise SAN-сховищем під сподом і з комерційною підтримкою ShapeBlue за платформою. Бюлетені безпеки проходять за описаною вище процедурою. Коли для CloudStack було опубліковано бюлетень, ми застосували виправлення до продуктивної хмари того самого тижня саме так, і кожен запущений інстанс клієнтів залишався в роботі весь час.

Віддамо належне тим, кому належить: спільнота Apache CloudStack і ShapeBlue роблять важку роботу з пошуку, виправлення та документування цих проблем. Якщо у вашій власній хмарі чекає оновлення, бо процедура здається ризикованою, ми радо пройдемо її разом з вами.

cta: Поговоріть з інженером

Related

• /what-we-do/storage-compute/dedicated-cloudstack/
• /what-we-do/storage-compute/private-cloud-olvm/
• /what-we-do/storage-compute/container-platform-openshift/