Openstack

Построение частного облака ЦЕРН с OpenStack началось ещё в 2011 году строительством тестовых облаков для физиков, чтобы исследовать облачные технологии для решения своих запросов. Использование ScientificLinux, разработанного CERN и Fermilab на основе распределения RedHat, облакабыли быстро построены на базеCompute и Dashboard услуг. Менее чем за два месяца, команда создала облако на основе OpenStack с контроллером, распределенной службы аутентификации, двумя узлами для вычислений, и узлом для ImageServices. Они использовали MySQL для своей базы данных, RabbitMQ для обмена сообщениями, и потому, что KVM были использованы ранее в CMS, он был выбран в качестве гипервизора. «Развернутая инфраструктура была очень стабильной и API слой OpenStack позволяет нам в полной мере управлять всем жизненным циклом виртуальных машин,» говорит Хосе Антонио, который руководил работой по реализации облако на CMS. Эта среда постепенно выросла до более чем 400 гипервизоров с высокой доступности на всех контроллерах OpenStack, используя функционал сообщества. Планирование и тестирование сейчас продолжается — удалось расширить облако до 15 000 гипервизоров с более 150 000 виртуальных машин.

Заключение

.

Является ли OpenStack технологией будущего, мейнстримом? Как знать. Возможно, это такой же неизведанный пока Клондайк, как Linux начала 90-х гг, когда мало кто о нем знал и совсем немногие видели. O penStack обладает большим потенциалом, но на сегодня трудно назвать его готовым продуктом, и особенно «бесплатным» сложно назвать.

O penstack — это унифицированные ручки для управления инфраструктурой. В условиях, когда гипервизоры отлажены до совершенства, именно эти ручки оказываются критическими. В существующем IT каждый болтик не должен быть произведением искусства и иметь совершенные размеры.

Он должен иметь такие размеры, чтобы хорошо закручиваться с гайкой. А если не закручивается, то никого не волнует икрустация по краю шляпки. Если закручивается — можно полюбоваться и поспорить чья школа лучше. В Openstack одинаково хорошо вкручивается и Hyper-V, и VMWare, и KVM. И они начинают работать как примитивные болтики. Никого не волнует мнение гипервизора о высокой политике (аллокации ресурсов или скедулинга), дело гипервизора — гипервизорить.

А вся важная логика (скедулинг, управление снапштами, правами доступа, настройками сети) — это openstack, который стандартен. И не только стандартен, но и очень модифицируем. Практически все люди, которые используют openstack, так или иначе его под себя патчили. Одному важно одно, другому — другое. Разница между гипервизорами в производительности в оптимальных настройках гостей несущественна. В реальной жизни её: а) не обнаружить из-за того, что девиация производительности железа больше разницы между производительностью гипервизоров (turboboost'ы)б) не обнаружить из-за того, что реальные ОС (применяемые в продакшене) не realtime и могут заняться более важными процессами, чем тест, в процессе тестирования. По CPU производительность у всех давно за 99% зашкалила.

По IO — надо смотреть на технологию виртуализации оборудования (которая к гипервизору постольку поскольку). При SR-IOV производительность будет одинаковая у любого гипервизора. При использовании паравиртуализованных драйверов вопросы гонки производительности уже давно ушли в район десятков гигабит (и немного отстают от производительности хоста).А вот COW-формат диска или RAW (самый острый вопрос, где IO может в 2−3 раза падать по сравнению с baremetall) — это решение администратора. Надо качество — COW, а если нужна производительность — RAW. Все гипервизоры умеют и то, и то. На практике «производительность гипервизоров» мгновенно заслоняется более важными вещами: «нет, ЭТО сделать нельзя, потому что в модели тулстека Х предполагается, что …», или «по архитектурным соображениям ограничение в тулстеке на число сетевых интерфейсов — 15».Заметим, это каждый раз ограничения тулстека, а не гипервизора. Иногда ограничения непонятны, иногда осмысленные.

Но чтобы об этом особо не думать, и существует openstack с унифицированным подходом. Ярче всего его видно на примере интеграции xenserver в openstack. Каждый хост xenserver является пулом. Никаких «пулов на несколько серверов». Никого не интересуют взаимоотношения двух хостов в пуле и выяснения кто из них мастер. Каждый диск делается в своём SR’е. Никаких «basecopy», взаимоотношений с драйвером SR, выясняющим где чьи данные и кто от кого произошёл. Никаких thincopy, с последующим мучением «ограничение на длину цепочки», «мультипликация IO на запись» и т. д. Выдали файл образа — запусти с него виртуалку. Надо сделать снапшот? Выдай полную копию. Всё. Вот эта грубоватая простота — она очень приятна. И получающаяся мультитенантность (никто, кроме openstack не даёт настоящего multitenancy «от» и «до») ещё один важный бонус.

Список использованных источников

информации.

http://www.openstack.org.