Наиболее важным шагом является тестирование перед обновлением. Если вы проводите модернизацию сразу после выпуска новой версии, скрытые ошибки могут помешать вашему продвижению вперед. Некоторые операторы, ответственные за развертывание, предпочитают подождать, пока не появится первая редакция с точкой. Тем не менее, если у вас есть важная реализация, вы можете следовать за разработкой и тестировать редакции, чтобы гарантировать, что ошибки для ваших вариантов использования устранены.
Даже если у вас есть то, что кажется почти идентичным архитектуре, которая описана в данном руководстве, каждое облако OpenStack имеет свои особенности. В результате, вы все равно должны проверить обновления между версиями в своей среде. Для этого вам необходим похожий клон вашей среды.
Однако, это не означает, что эта среда должна быть такого же размера или использовать идентичное оборудованию производственной среды — немногие из нас имеют такую роскошь. Учитывать аппаратуру и масштаб обновляемого облака важно, но приводимые здесь советы помогут вам избежать таких невероятных стоимостных затрат::
- Используйте свое собственное облако.
-
Простейшим местом для начала тестирования следующей версии OpenStack является создание новой среды внутри вашего собственного облака. Это может показаться странным, в особенности двойная виртуализация, используемая для управления вычислительными узлами, но это верный способ очень быстро проверить вашу конфигурацию.
- Используйте общедоступное облако
-
В особенности по той причине, что свое собственное облако вряд ли будет иметь достаточно места для масштабирования теста на уровень всего облака, рассмотрите возможность использования общедоступных облаков для испытания пределов масштабируемости конфигурации облака контроллера. Большинство общедоступных облаков выставляют почасовые счета, а значит, могут быть недорогими для выполнения даже тестирования со многими узлами.
- Сделайте еще одну конечную точку хранения в той же системе
-
Если вы используете внешнее подключаемое устройство хранения или совместно используемую файловую систему в вашем облаке, то во многих случаях вы можете проверить, работает ли оно, создав второй совместно используемый ресурс или конечную точку. Это действие позволяет проверить систему, прежде чем доверить новой версии свою систему хранения.
- Следите за сетью
-
Даже при маломасштабном тестировании, поиск избыточных сетевых пакетов для определения того, не происходит ли что-то страшное, будет неправильно для взаимодействия между компонентами.
Чтобы настроить тестовую среду, вы можете использовать один из нескольких способов:
-
Выполните полное руководство по установке, с использованием Руководство по установке OpenStack для вашей платформы. Проверьте окончательные файлы настройки и установленные пакеты.
-
Создайте клон своей автоматизированной инфраструктуры настройки с измененными URL-адресами репозитория пакетов.
Изменяйте конфигурацию, пока она еще работает.
Любой подход справедлив. Используйте подход, который соответствует вашему опыту.
Предварительное тестирование модернизации системы отлично подходит для получения рабочей настройки; однако, важно отметить, что историческое использование системы и различий во взаимодействия с пользователем может также влиять на успех обновления. Мы наблюдали опыты, при которых миграции базы данных сталкивались с ошибкой (позже исправленной!) из-за небольших различий в таблицах между новой установкой Grizzly и установками, которые мигрировали с Folsom на Grizzly.
Искусственное масштабное тестирование может идти только до сих пор. После того, облако будет обновлено, необходимо обратить пристальное внимание на аспекты производительности вашего облако.