Ох, вы затрагиваете довольно много вопросов, где информация коммерческая. Что смогу — расскажу. Гипервизор qemu-kvm. RDMA используется только для кластерной ФС, она не требует наличия IPoIB. В нашем случае IPoIB используется для коннекта хостов при построении SDN сетей. Кластерная ФС с поддержкой RDMA. Измерения пропускной способности IPoIB проводились с помощью iperf, тестирование производительности RDMA проводилось с помощью утилит из OFED. Конечное оборудование — коммутаторы Mellanox SX6036, SX6025 и в серверах у нас стоят ConnectX-3 VPI. В качестве spine коммутаторов используются Mellanox SX6036, которые выполняют роль SM. В каждом кластере несколько таких коммутатором, на каждом настроем SM с различным приоритетом. В облаке используется RHEL 6.x, используются нативные драйвера, поставляемые с ОС.
Это решение появилось на рынке относительно недавно, в период поиска (несколько лет назад) оптимального решения для нашего облака на Компрессоре его ещё не было. А нам вторую облачную площадку нужно было подстроить под первую. Но даже если рассматривать, цена за коммутаторы с поддержкой cut-through все равно значительно выше, чем за оборудование Mellanox.
1. Под «косвенно ускорить работу, например, СХД» подразумевалось увеличить производительность дисковой подсистемы за счет перехода коннекта нод гипервизора к кластерной ФС с Ethernet на RDMA. Плюс СХД будут подключаться напрямую по Infiniband, а не по FC, как это было у нас ранее.
2. Потому что был необходим RDMA, для увеличения производительности нашей кластерной ФС. Также, как отмечал выше, в Infinband возможности построения Leaf-Spine топологии, RDMA, автонастройки уже существуют давно и проектировались на уровне протоколов, а не добавлялись как AD-HOC решения, как Ethernet-е. Плюс Infiniband дешевле чем 40G.
Это управлемый процесс. Как пожелает заказчик. У нас в публичном облаке данные хранятся на централизованных СХД, не на локальных дисках серверов. Так что выход из строя физических серверов нам не страшен. Где хранятся данные на площадке заказчика зависит от самого заказчика.
В двух словах: раньше без сертификата многие не ставили *nix для решения этого класса задач. Стать первым сертифицированным поставщиком в РФ – это действительно достижение. То есть опенсорсное решение теперь может появиться даже в госкомпаниях. Мне кажется, открытый исходный код в таких ситуациях — это очень хорошая тенденция.
У нас своё облако, написанное в основном на Python с некоторыми модулями на C++ (для скорости работы). В качестве БД мы используем документо-ориентированные СУБД. Web-интерфейс на jQuery, кстати, WEB-бэкенд тоже Python. ОС — RedHat, а nginx и haproxy используются для балансировки, гипервизор — RedHat KVM, управление конфигурациями Puppet со стандартными модулями, для разливки мы используем Cobbler. Всё ПО ставится из стандартных пакетов .rpm, которые собираются при помощи Koji. В общем, мы системный интегратор, который очень любит открытый софт и системы, поэтому мы всё это подружили вместе.
У нас 3 дата-центра. 70, 110 и 800 стоек соответственно. Облако живет на двух площадках из трех. Серверы заказчиков равномерно распределены по всему физическому оборудованию, а диски этих серверов хранятся на централизованной СХД. Данные всех заказчиков на блочном уровне хранятся вперемешку. Чтобы изъять какую-либо информацию нужно вывезти несколько десятков стоек с обеих площадок, да еще заехать в офис заказчика и добыть у его админа пароль. Иначе само железо – это просто неконсистентная каша из данных. Другими словами, гораздо легче просто узнать у вас пароль. Само по себе изъятие оборудование ни к чему не приведет. Это не dedicated серверы, которые можно вычленить из общей массы. Могу сказать, что прецедентов у нас за 21 год работы с проверками не было.
Компания КРОК может и хотела бы сделать заказчика совсем счастливым и задублировать все, что возможно, но в части каналов связи решение принимает сам заказчик исходя их его финансовых возможностей и критичности простоев для его бизнеса. Здесь мы можем только давать советы и рекомендации. Что касается безопасности, то сейчас у нас в облаке живет уже более 40 заказчиков. Часть из них крупные компании со штатом более 1000 человек, и часть из них вынесли к нам все свое ИТ полностью. Их специалисты по ИБ задавали нам очень много вопросов, проверяли большое количество бумаг и остались довольны. Вообще, безопасность в облаке у хорошего провайдера чаще всего выше, чем у себя.
Менеджер проекта, техменеджер по части платформы, два инженера по части почты и AD, инженер по части терминального доступа, инженер по части бэкапа. 2 человека со стороны заказчика, один эксперт со стороны материнской компании.
Ок. Уже ответил выше: закончим тесты и покажем. Наверняка у вас есть ещё вопросы по «облаку» — было бы здорово услышать все параметры, которые вам интересны для сравнения. Включая, может быть, не только сугубо технические.
У нас 2 тира (FC и SATA) дисков с онлайн миграцией между ними. С производительностью все хорошо. Обязательно покажем замеры дисковой и сетевой производительности как закончим цепочки тестов.
Не совсем так. Все ВМ взяты примерно одинакового размера (соотношение 1 к 4-м между ядрами и оперативной памятью). Разница в показателях связана с типом процессора, использующегося на физических серверах, предназначенных для запуска ВМ, а также политикой конкретного «облака» по выделению вычислительных ресурсов (не все выделяют гарантированные мощности). Отличаться будет, но не в 2 раза. Опять же из-за политики выделения.
Обратите внимание: мы выбрали такую методологию поскольку она предложена независимой стороной и может быть легко повторена для любого «облака». Дальше мы планируем проводить дополнительные тесты и расскажем об их результатах.
Вы абсолютно правы, такие вопросы нам тоже часто задают. Не стал их подробно рассматривать в посте, иначе бы его никто не осилил)
Вот что мы обычно в таких случаях отвечаем:
1. Интеграция облака с собственным ДЦ возможна, как на уровне платформы (построение горизонтальных распределенных L2 сетей, настройка динамической маршрутизации, настройка внутренней адресации в облаке), так и на уровне прикладного ПО.
2. По части миграции в облако крупных задач, мы стараемся организовать выделенного инженера, который помогает заказчику в планировании и проведении работ от начала и до конца.
3. Доступ к порталу самообслуживания, личному кабинету, а также к функциям управления виртуальной инфраструктурой через API защищаются SSL по умолчанию.
4. AIX машины можно всегда разместить рядом в ЦОД и интегрировать с виртуальными машинами облака.
5. У нас сейчас есть две зоны облака, представленные двумя удаленными дата-центрами.
6. Процесс обновления ОС и патч менежмент микрокодов инфраструктурных компонент облака происходит на периодической основе не реже чем раз в 2 неделе. О крупных обновлениях производится дополнительное уведомление заказчиков.
7. По части размещения дополнительного оборудования. Всегда пожалуйста. Также часто мы предлагаем заменить физическое оборудование его виртуальными аналогами, если такая возможность есть.
8. Мы предоставляем программные интерфейсы для доступа к управлению облачной инфраструктурой, поэтому наши клиенты могут самостоятельно реализовать любые требования в части дополнительных сервисов.
9. Поддержка ( + планирование, эксплуатация) всех наших заказчиков осуществляется по третьей редакции ITIL. Все эти процессы задокументированы и строго соблюдаются.
Да, вы правы, Амазон работает с юридическими лицами. Но наиболее широко он представлен на рынке по работе с физическими лицами, для которого характерно минимальное участие службы технической поддержки и максимальная автоматизация сервисов. Этим же объясняется возможность самостоятельно протестировать «облако».
А специальные предложения, индивидуальный подход, круглосуточная техническая поддержка – это как раз атрибут enterprise-рынка, на котором живет КРОК.
Это будет не совсем обзор провайдеров, а методология их выбора. То есть будет приведен перечень вопросов, который разумно задавать провайдерам при исследовании рынка.
Мы имеем богатый опыт работы с GPFS. Все началось лет 5-7 назад, когда мы для одного крупного авиазавода строили вычислительный кластер на GPFS + Infiniband + RHEL. Кластер был на 400+ узлов. Данная связка компонент зарекомендовала себя с лучшей стороны. Именно поэтому она была выбрана в качестве базиса при построении облачной платформы.
Минусов в GPFS за более чем в 3 года эксплуатации нашей облачной платформы мы видим не так много.
2. Потому что был необходим RDMA, для увеличения производительности нашей кластерной ФС. Также, как отмечал выше, в Infinband возможности построения Leaf-Spine топологии, RDMA, автонастройки уже существуют давно и проектировались на уровне протоколов, а не добавлялись как AD-HOC решения, как Ethernet-е. Плюс Infiniband дешевле чем 40G.
Вот что мы обычно в таких случаях отвечаем:
1. Интеграция облака с собственным ДЦ возможна, как на уровне платформы (построение горизонтальных распределенных L2 сетей, настройка динамической маршрутизации, настройка внутренней адресации в облаке), так и на уровне прикладного ПО.
2. По части миграции в облако крупных задач, мы стараемся организовать выделенного инженера, который помогает заказчику в планировании и проведении работ от начала и до конца.
3. Доступ к порталу самообслуживания, личному кабинету, а также к функциям управления виртуальной инфраструктурой через API защищаются SSL по умолчанию.
4. AIX машины можно всегда разместить рядом в ЦОД и интегрировать с виртуальными машинами облака.
5. У нас сейчас есть две зоны облака, представленные двумя удаленными дата-центрами.
6. Процесс обновления ОС и патч менежмент микрокодов инфраструктурных компонент облака происходит на периодической основе не реже чем раз в 2 неделе. О крупных обновлениях производится дополнительное уведомление заказчиков.
7. По части размещения дополнительного оборудования. Всегда пожалуйста. Также часто мы предлагаем заменить физическое оборудование его виртуальными аналогами, если такая возможность есть.
8. Мы предоставляем программные интерфейсы для доступа к управлению облачной инфраструктурой, поэтому наши клиенты могут самостоятельно реализовать любые требования в части дополнительных сервисов.
9. Поддержка ( + планирование, эксплуатация) всех наших заказчиков осуществляется по третьей редакции ITIL. Все эти процессы задокументированы и строго соблюдаются.
А специальные предложения, индивидуальный подход, круглосуточная техническая поддержка – это как раз атрибут enterprise-рынка, на котором живет КРОК.
Минусов в GPFS за более чем в 3 года эксплуатации нашей облачной платформы мы видим не так много.