Как стать автором
Обновить

Тендер по Private Cloud — часть первая

Время на прочтение 4 мин
Количество просмотров 5.5K
В данной стать я хочу поделиться опытом/методологией по реализации 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. Для этого организовывались встречи с производителями железа и ПО.

Железо

У нас был следующий выбор:
  1. собрать самим из тех элементов, которые мы привыкли использовать: серверы HP, СХД EMC и NetApp и сеть из Cisco.
  2. следовать архитектуре FlexPod
  3. использовать 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 (от начального до самого производительного).

image

Каждая серия в свою очередь состоит из ряда моделей. В отличии от 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.
Теги:
Хабы:
+11
Комментарии 10
Комментарии Комментарии 10

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн