Официально объявлено о выходе OpenStack Kilo, уже одинадцатой версии OpenStack. Пресс-релиз уже перевели на русский и обсуждают на OpenNET.ru.

Одновременно опубликовали и радующую глаз статистику по разработчикам этой версии OpenStack. Как и всегда радуемся успехам наших соотечественников из Mirantis, и ведущей роли наших коллег из Red Hat.



Из интересных новостей стоит отметить инициативу группы разработчиков OpenStack по переписыванию компонентов Swift на golang. Теоретически это должно повысить производительность, а как оно реально получится - посмотрим.

Вообще, в последнее время за подсистемы хранения данных взялись серьезно. Идея о том, чтоб из "рассыпухи" серверов собрать отказоустойчивое хранилище данных (необязательно файлов, можно и оперировать данными на уровне приложений, целыми объектами), оказалась не только заманчивой, но и вполне реализуемой. Проблема в том, что не только сетевые задержки превосходят задержки при работе с грампластинками, но и демоны, обеспечивающие работоспособность системы в целом, тупят и тормозят. Неудивительно, что есть желание переписать отдельные компоненты на более шустром компилируемом современном языке, который бы предоставлял возможности интерпретируемых. Но даже если и не перепишут, то уже достигнутый результат уже нарушает сон представителей проприетарных компаний (да, NetApp, пора перестраиваться, иначе события пойдут по плохому сценарию). А вот кое кто быстро перестраивается. Например Seagate, традиционный участник RICON, который обещает вскоре открыть Kinetic Storage platform, свое решение для облачного хранилища объектов. Это очередной уровень абстракции - хранить не файлики, а сразу готовые объекты уровня бизнес-логики. Seagate собирается запрыгнуть в этот поезд, чтобы по праву архитектора подсистемы устанавливать стандарты и технические требования, обеспечивая своим продажникам преимущество.

У Red Hat, само собой, есть хорошее портфолио решений для облачных хранилищ. К сожалению, из-за того, что тема только пошла, варианты перехлестываются (Ceph vs. Gluster). Это очень плохо, т.к. создает вредный юниксвэй из вариантов, и решения по которому заказчики принимать не хотят. К счастью, в марте этого года Red Hat предложило свое архитектурное видение, где четко разграничило сферы применения. Берите Gluster для использования в Enterprise Virtualization, аналитических задачах, и для разделения и синхронизации данных уровня Enterprise. А если вы не зарабатываете деньги для OpenStack и AWS берите Ceph. Для хранения архивных данных используйте любой вариант из этих двух.

Оба проекта до сих пор на стадии "work-in-progress", но нужно отметить, что Gluster начали пораньше, и фич в нем больше - лучше производительность на малых файлах, интеграция с SELinux, развитый фреймворк для управления. Ceph пока застрял на POSIX-интерфейсе (CephFS). Напомним мнение инженера Seagate, James Hughes, который на RICON 2013 сказал, что "Any distributed filesystem like GlusterFS or Ceph that tries to preserve the POSIX API will go the way of the dodo bird". Может и не стоить тащить этот POSIX? Но хозяин-барин, конечно.

Напомним, основной проблемой POSIX, архитектурно подразумевающей существование в системе некоего синглтона, эффективно упорядочивающего операции над FS самим своим существованием, является то, что это резко усложняет масштабируемость. Если кто не верит, то задайтесь вопросом, как получив файловый дескриптор, узнать по нему, не изменилось ли содержимое файла с момента открытия и как предохраниться от неожиданных изменений? Рекомендуем дальше поинтересоваться тонкостями на любой из конференций, где будут наши коллеги, например, на том же FOSDEM. К сожалению, мы на айти-мероприятиях в России, часто встречались со свежей мыслью, что разработчики должны во что бы то ни стало следовать стандартам из 1970x-1990x (X11, SysV, POSIX, файловый API для всего - от конфигураций до хранения данных, текстовички и текстовые протоколы, т.к. "читать глазами" кококо, пайпы и т.п.). Это лишь показывает невысокий уровень знакомства с открытыми системами у ряда коллег-аналитиков. Кстати, Embedded-разработчики вышли из положения до тупости просто - скидывать файлы на телефон или аудиоплэйер можно лишь через спецпротокол (несоответствующий POSIX), либо переключив его в режим флэшки (отдав проблемы на откуп хостовой системе). А представьте, что Vkontakte или Twitter лочили бы всю систему, когда кто-нибудь постил фоточку. К счастью, социальные сети построены не на POSIX-стандарте, и поэтому они быстро и хорошо работают.

Вернемся к Ceph. Несоответствие (или неполное соответствие) POSIX, это, как полагает ряд экспертов, не такая уж и проблема. А вот отсутствие fsck - это уже стоп-слово.


Играл с клубком, забыл stop word