- tocdepth
2
Подготовка целевой архитектуры
После того как дана оценка существующей инфраструктуре и рабочим нагрузкам, организация может использовать полученные результаты, чтобы подготовить план миграции нагрузок в облако с помощью проектных решений, основанных на определении требуемой вычислительной мощности, объема, выборе местоположения сервисов и сетевого подключения. Подобно локальной инфраструктуре облачная среда Cloud.ru также может быть спроектирована для обеспечения высокой доступности, восстанавливаемости и масштабируемости. Конкретные технические конфигурации зависят от конкретных требований конечного пользователя. Облачная инфраструктура Cloud.ru построена на базе платформы виртуализации, которая обеспечивает динамическую балансировку нагрузки на серверы и системы хранения данных для достижения оптимальной производительности.
Составными частями платформы виртуализации являются:
- Аппаратный гипервизор
Механизм, разделяющий ресурсы физического сервера между несколькими виртуальными машинами.
- High Availability (HA)
Механизм, позволяющий восстанавливать работоспособность виртуальных машин после аппаратного сбоя узлов виртуализации.
- Сервис балансировки рабочих нагрузок
Механизм, равномерно распределяющий ВМ между всеми узлами кластера и обеспечивающий заданную производительность виртуальных машин в штатном и нештатном (в случае сбоев) режимах работы.
- Сервис онлайн-миграции ВМ
Механизм «живой» миграции ВМ между узлами кластера для сервисного обслуживания без прерывания работы пользовательских ВМ.
Проектирование
Требования к облачной инфраструктуре Cloud.ru определяются на основе требований приложений, собранных в ходе первоначальной оценки существующих рабочих нагрузок и инфраструктуры. Существует множество способов проектирования каждой части среды Cloud.ru, например, выбора вычислительных ресурсов и сетевых соединений. Независимо от этого, окончательный проект должен соответствовать установленным требованиям в рамках ограничений и допущений. Ограничения — любые ограничивающие факторы, которые могут повлиять на проект. Они могут быть связаны с проектом, например, бюджет или сроки. Ограничения могут быть техническими, например, существующая архитектура приложения, которая не может быть изменена. Предположения могут быть сделаны во время инвентаризации, поскольку не вся необходимая информация может быть доступна сразу. Выявленные предположения должны быть подтверждены, чтобы проектные решения принимались на основе правильной информации. Кроме того, любые риски, как технические, так и нетехнические, которые могут возникнуть в результате принятия решения о выборе конкретного проекта, должны быть задокументированы и рассмотрены с учетом возможных стратегий снижения рисков. Управление рисками может варьироваться в зависимости от их воздействия и уровня усилий. Риски, оказывающие большое влияние, скорее всего, должны быть уменьшены, в то время как организация может принять риски, оказывающие малое влияние. После завершения разработки конкретного проекта важно задокументировать это решение, включая обоснование и любые связанные с ним риски. Также важно отметить, какие требования были выполнены конкретным проектом, чтобы убедиться, что окончательный проект отвечает всем установленным требованиям и бизнес-потребностям.
Масштабируемость
Масштабируемость не имеет стандартной метрики, используемой в отрасли. Как правило, для определения того, насколько гибко система справляется с изменениями спроса, можно провести тестирование производительности или нагрузки. Например, тестирование производительности может быть проведено для измерения того, сколько времени требуется системе для добавления дополнительных ресурсов и удовлетворения пикового спроса. Система, которой требуется всего одна минута для добавления дополнительных ресурсов, является более масштабируемой, чем система, которой требуется час для выполнения того же действия.
Существует несколько вариантов масштабирования облачной инфраструктуры Cloud.ru. Организации могут начать с масштабирования кластера vSphere путем добавления хостов для удовлетворения растущего спроса. Организации могут включить автоматическое распределение ресурсов, например Distributed Resource Scheduler (DRS). Данные процессы автоматизированы в облаке Cloud.ru.
Если масштабирование кластера vSphere достигает максимальных значений конфигурации Cloud.ru или не отвечает потребностям бизнеса, следующим вариантом является масштабирование путем создания дополнительных кластеров vSphere в рамках платформы Облако VMware. Важно определить, когда следует создать новый кластер vSphere, чтобы спланировать работу на второй день и управлять ростом среды.
Облачная среда Cloud.ru спроектирована таким образом, чтобы ее можно было повторять. Модульная конструкция облегчает тиражирование или расширение среды для удовлетворения быстро растущего спроса.
Высокая доступность
Высокая доступность может быть достигнута для физической инфраструктуры, виртуальной инфраструктуры и сервисов приложений. Высокая доступность измеряется временем безотказной работы — количеством времени, в течение которого сервис функционирует. Cloud.ru имеет несколько физических центров обработки данных. Центры обработки данных проектируются независимыми друг от друга, чтобы сбой в одном центре обработки данных не повлиял на другой.
Решения Cloud.ru по своей природе обеспечивает высокую доступность виртуальных машин, работающих в облачном ЦОДе. При отказе хоста ESXi система vSphere HA автоматически перезапускает виртуальные машины с отказавшего хоста ESXi на другие хосты ESXi в том же кластере vSphere.
Восстанавливаемость
Возможность восстановления измеряется двумя основными показателями:
Целевая точка восстановления (RPO) — объем потери данных, который может выдержать организация.
Целевое время восстановления (RTO) — количество времени простоя, которое может выдержать организация.
Компания Cloud.ru отвечает за возможность восстановления виртуальных машин управления облачной инфраструктурой. Однако простого использования SLA виртуальной инфраструктуры может быть недостаточно для удовлетворения требований приложения. Организация должна быть готова к отказам отдельных виртуальных машин путем разработки надлежащего решения для аварийного восстановления и резервного копирования.
При планировании аварийного восстановления приложения должны быть сгруппированы на основе критичности бизнеса, требований RPO/RTO и зависимостей приложений. В процессе восстановления приоритет должен отдаваться критически важным приложениям с более низким RTO. Взаимозависимые приложения должны восстанавливаться вместе для обеспечения надлежащей функциональности. Важно выбрать подходящее решение для аварийного восстановления на основе требований к RPO приложений. Для снижения RTO организация может автоматизировать процесс восстановления, например, обход отказа виртуальной машины и возврат к отказу.
Такие инструменты, как Cloud Disaster Recovery и Site Recovery, могут предоставлять возможности аварийного восстановления для облачной инфраструктуры Cloud.ru.
Для скорейшего обнаружения сбоя виртуальной машины или приложения необходимо обеспечить надлежащий мониторинг. Инструмент мониторинга может быть настроен на оповещение о конкретных проблемах инфраструктуры и/или приложений и предоставляет средства для уведомления ответственных лиц.
Резервное копирование рабочих нагрузок и/или приложений является критически важным для комплексного решения аварийного восстановления. Политики хранения резервных копий и планирование заданий резервного копирования должны быть настроены в соответствии с требованиями организации к RPO. Необходимо обеспечить соответствующее сетевое подключение с достаточной пропускной способностью, чтобы задания резервного копирования не влияли на производственный трафик. Окно резервного копирования должно быть запланировано на нерабочее время, чтобы избежать влияния на производственные нагрузки. Резервные копии должны храниться вне помещения, в месте, отличном от того, где находятся рабочие нагрузки. Организация должна регулярно тестировать и проверять резервные копии для обеспечения надлежащего восстановления рабочих нагрузок.
Ресурсы платформы Облако VMware также можно использовать в качестве места аварийного восстановления для локальной среды. Организация должна иметь соответствующее сетевое подключение, чтобы пользователи могли продолжать доступ к своим рабочим нагрузкам после объявления бедствия. В организации должен быть разработан план возврата рабочих нагрузок в исходное местоположение после восстановления инфраструктуры. Для проверки процедур аварийного восстановления организация должна регулярно проводить тестирование и обход отказа рабочих нагрузок на платформу Облако VMware и обратно.
для Dev & Test