В данной стать я хочу поделиться опытом/методологией по реализации Private Cloud. Здесь я приведу вопросы, которыми мы задавались по ходу реализации и как они решались.
.
Мы участвовали в тендере по разработке Private Cloud сервиса для одной крупной европейской организации. Цель данного тендера — предложить инфраструктуру, предоставляющую клиенту сервисы IaaS и PaaS. Ниже приведу ключевые моменты тех. задания:
- основными операционными системами являются Windows и Linux на платформе x86
- «стандартный» список ПО для PaaS сервисов (web, database, application server, etc.), включая базы данных Oracle
- желательно так же предложить Solaris x86
- инфраструктура должна располагаться в двух датацентрах (расстояние < 50 км)
- 6 типов виртуальных машин (от 1 vcpu до 10 vcpu)
- 4 сервиса (SLA): от бронзы (best effort) до платины (RPO: realtime, RTO: 2h)
- твердый заказ на 1000 виртуальных машин, с возможным ростом до нескольких тысяч
В Private Cloud аппаратная часть не играет ключевой роли: серверы, СХД и прочее можно приобрести у кого угодно, игроков на рынке предостаточно. Все изюминка находится в программной части, которая будет управлять/дирижировать всем и вся. С этим сложнее.
После подробного изучения тех. задания, мы определи два направления: изучения предложений аппаратной части и предложений ПО Private Cloud. Для этого организовывались встречи с производителями железа и ПО.
Железо
У нас был следующий выбор:
- собрать самим из тех элементов, которые мы привыкли использовать: серверы HP, СХД EMC и NetApp и сеть из Cisco.
- следовать архитектуре FlexPod
- использовать VCE Vblock (аппаратно-программное решение)
NB: Интегрированные решения IBM или HP мы не рассматривали, так как они были наши конкуренты по тендеру.
Первый вариант был вычеркнут достаточно быстро, потому что клиент хотел решения в виде блока и максимально интегрированное. К тому, же стратегически важно было предложить клиенту решение, которое не привязывает его руками и ногами к нашей организации. Полагаясь на готовые решения, мы избавлялись от проблемы с поддержкой и развитием архитектуры.
Вкратце ключевые моменты FlexPod и Vblock
FlexPod это модель (blueprint) проектирования инфраструктуры для Cloud, состоящий из Cisco UCS (compute & network) и NetApp (storage). На следующей картинке приведена стандартная архитектура FlexPod FCoE and 10 GbE.
Собирать и настраивать всю инфраструктуру придется самим, но для этого существует документация доступная на сайтах Cisco/NetApp, как например вот эта. Архитектура, получившая сертификат FlexPod дает право на единую службу поддержки, не зависимо от источника проблемы: compute, network, storage. Правда для одной части наших сотрудников единая служба поддержки это абсолютно не аргумент.
Гибкость архитектуры FlexPod заключается в том, что можно выбрать любую подходящую СХД NetApp, необходимое количество шасси и серверов Cisco UCS. Можно добавить внутренную сеть SAN, если на пример протокол FCoE вас не удовлетворяет или если консолидация SAN & LAN на одном устройстве (Cisco Nexus 5K) вам так же не подходит. В качестве виртуализации есть выбор из VMware, Hyper-V, Citrix.
Vblock это готовый продукт, очень похожий по внутренностям на FlexPod: Cisco UCS (compute & network) и EMC (storage), а так же включающий кроме аппаратной части еще и гипервизор VMware и средства управления. В отличии от стандартного FlexPod, Vblock всегда использует отдельный SAN switch Cisco MDS для доступа к СХД.
Всю настройку и сборку реализуeт VCE. Существует несколько серий Vblock: 100, 300 и 700 (от начального до самого производительного).
Каждая серия в свою очередь состоит из ряда моделей. В отличии от FlexPod, VCE является юридическим лицом отвечающим за Vblock. В данном случае поддержка выглядит серьезней, чем для FlexPod. Все изменения архитектуры, которые вы собираетесь реализовать, должны быть подтверждены консорциумом VCE, в противном случае теряется сертификат Vblock.
NB: Если в аппаратной части FlexPod, заменить СХД NetApp на EMC, то мы почти получим Vblock. Что такое Cisco UCS можно почитать здесь.
После встреч с Cisco/NetApp и VCE, мы остановились на решении FlexPod по следующим причинам:
- FlexPod поддерживает несколько гипервизоров, в отличии от Vblock
- FlexPod обладает большей гибкостью при построении аппаратного комплекса. К примеру если у вас уже есть СХД NetApp, то добавив Cisco UCS и следуя инструкциям Cisco/NetApp вы получите инфраструктуру FlexPod. В случае с Vblock такое не возможно, приходится покупать весь «боекомплект».
- изменения инфраструктуры FlexPod не подвержены таким жестким правилам как в случае с Vblock. К примеру, блейд серверы всегда добавляются только парами для Vblock.
- для того, чтобы предоставить высокий уровень сервиса с критичными RTO/RPO, нам необходимо решение для синхронной репликации данных. В случае с СХД NetApp мы получаем встроенное решение MetroCluster, входящее во все модели FAS 3xxx и 6xxx. Для Vblock это реализуется посредством RecoverPoint или Vplex, но это стоит немалых денег (SRDF/S не в счет).
- NetApp, это унифицированная система хранения данных, а так же система резервного копирования (back-up), таким образом нет нужды приобретать дополнительное решение такие как EMC Avamar.
У Vblock несомненно есть свои аргументы, но в данном случае, приведенные выше элементы для нас оказались важнее. По этой ссылке интересующиеся найдут более развернутое сравнение.
Во второй части, я расскажу у дизайне FlexPod, а затем о програмнной составляющей Private Cloud.
Автор: dargo
