Существуют понятия, которые принято использовать как в профессиональном общении, так и в маркетинге, подразумевая, что они строго определены и все понимают их одинаково. Но часто оказывается, что у ряда терминов, вокруг которых идет оживленная дискуссия в ИТ-сообществе, точных определений не было и нет, а договориться об едином их значении, конечно, все забыли.

Например, понятие «enterprise readiness». С тех пор, как мы всерьез заговорили об автоматизации предприятий, его с уверенностью используют как в технической документации, так и при поддержке продаж все, кому не лень. Но строгого определения у него нет! Есть общее понимание «систем уровня enterprise-ready», или «систем масштаба предприятия», как решений, готовых к использованию крупными организациями из произвольных отраслей человеческой деятельности. Часто решениями enterprise-ready просто называют очень дорогие решения – стоимостью более миллиона долларов, например. Казалось бы – курьез. Но этот курьез задает уровень дискуссии.

Надежность, доступность, обслуживаемость

Говоря об ИТ-решениях «enterprise-уровня», под «enterprise» понимают любые крупные организации и управляющие компании, но не ИТ-компании. Это важно, потому что такие организации ориентируются на определенные стандарты и серийные продукты в сфере ИТ, им важно, чтобы они могли самостоятельно эксплуатировать приобретаемые ими решения; для них критична отказоустойчивость и надежность функционирования ИТ-систем. Поэтому мы предпочитаем называть системами «масштаба предприятия» программно-аппаратные решения, предназначенные для работы в крупных организациях и характеризующиеся:

• надежностью (reliability): большим временем наработки на отказ;
• высокой доступностью (availability): даже в случае отказа одного из компонентов, системы должны продолжать функционировать без заметного снижения эксплуатационных свойств;
• обслуживаемостью (serviceability): т.е. возможностью достаточно быстрого восстановления или замены вышедшего из строя компонента при наименьших затратах как со стороны организации-эксплуатанта, так и поставщика.

И это придумано не нами. Еще в 1960-е гг. компания IBM использовала в рекламе своих мейнфреймов аббревиатуру «RAS» – Reliability, Availability, Serviceability. Можно выделять и другие характеристические свойства, но, так или иначе, они легко сводятся к RAS. Именно здесь концентрируются основные ожидания крупных организаций от ИТ.

Впрочем, надежность, доступность и обслуживаемость тоже понимают по-разному. В частности, существует некое частное мнение о том, что обязательным требованием высокой доступности системы является свойство локальности данных (data locality). Но ведь и у локальности данных нет строгого определения! Идея локальности данных заключается в том, что данные должны физически находиться «где-то рядом» с тем местом, где они обрабатываются. Разумеется, каждый производитель реализует локальность данных по-своему. Забавно, что именно реализации локальности данных вызывают больше всего вопросов – хотя по отношению к enterprise readiness в целом, как мы видим, это свойство даже не второго, а третьего порядка. Но раз уж именно это свойство enterprise-ready-систем порождает такие ожесточенные споры, давайте выясним, какие варианты решений обеспечения локальности данных существуют в контексте готовности к нагрузкам и эксплуатации в «масштабе предприятия».

Локальность данных

Для начала нужно разобраться с понятием локальности данных и примерами ее реализации в различных классах инфраструктурных и платформенных систем.

О каком уровне локальности данных мы говорим? О локальности данных по отношению к процессорным гнездам? Или об организации взаимодействия между географически распределенными центрами обработки данных? Давайте договоримся, что речь идет о гиперконвергентных системах, т.е. о виртуализационных комплексах на основе x86-узлов без внешних систем хранения – сегодня, именно они становятся фактическим стандартом реализации виртуализированной инфраструктуры для крупных и средних организаций.

Так вот, гиперконвергентная система – это, по сути дела, множество узлов, на которых работают виртуальные машины. Виртуальные машины сохраняют данные на внутренних накопителях хостов виртуализации. Свойство локальности данных подразумевает, что каждая виртуальная машина записывает данные на накопители, находящиеся на том же физическом узле, что и виртуальная машина – чтобы не перегружать сеть. В дальнейшем эти данные будут скопированы на другие узлы для обеспечения избыточности хранения данных, но чтение виртуальной машиной осуществляется в «своем» физическом узле.


Рис. 1. Гиперконвергентная система объединяет ресурсы из нескольких узлов в вычислительный пул, а локальные накопители узлов делегирует в единый пул хранения. Том виртуальной машины ВМ₁, размещённой на первом узле, первую реплику своих блоков данных записывает на локальные накопители.

Но что делать, если узел выходит из строя? Виртуальная машина, разумеется, будет перемещена на другой физический узел. Но должны ли туда же, к этой виртуальной машине, «переехать» все ее данные? Главный плюс этого подхода – виртуальная машина может читать свои данные в большей степени локально, чем по сети. Главный минус – перенос данных перегружает сеть, причем, как показывает опыт, довольно значительно. Поэтому в нашем варианте реализации, который мы применили в гиперковергентной вычислительной платформе «Скала-Р», мы сознательно не стали делать перестройку хранилища с переносом данных виртуальных машин автоматической. При этом мы исходили не из умозрительных представлений о том, что такое локальность данных, а из фактических показателей доступности системы, которым соответствует «Скала-Р».


Рис. 2. При сбое узла виртуальные машины с него, в том числе ВМ₁, мигрируют на другой узел, первая реплика для тома ВМ₁ записывается теперь на локальные накопители второго узла – это его новая локальность. Но нужно ли автоматически перестраивать весь пул хранения так, чтобы на накопителях второго узла оказалось максимум блоков данных тома ВМ₁?

Почему мы так делаем? Потому что мы считаем, что ИТ-инфраструктура не должна быть избыточной, ее сложность и финальная стоимость должны быть оправданными, а поведение – предсказуемым. Как примеры хороших практик можно привести реализации таких систем мониторинга и управления, как HP OpenView, IBM Tivoli, BMC Patrol – они могли в определенных ситуациях проактивно выполнять упреждающие и корректирующие действия, но по умолчанию эти возможности были отключены, и происходило только оповещение системного администратора.

Мы считаем такую политику очень разумной, и аналогия с политиками поведения гиперконвергентных систем здесь усматривается прямая. Перенос виртуальных машин со сбойного узла на другие – это естественное, предсказуемое действие, необходимое для обеспечения высокой доступности. Перенос же локальных данных, неизбежно повышающий нагрузку на сеть, с нашей точки зрения, следует оставить на усмотрение оператора.

Межузловая локальность в гиперконвергентных системах

Действительно, требуется ли локальность данных для эксплуатации систем в масштабе предприятия, и если она нужна, то в каком варианте реализации? В начале 2010-х гг. ранние гиперконвергентные системы проектировались из соображений независимости от производительности сетевой инфраструктуры. Самым распространенным сетевым решением в ЦОДах организаций был гигабитный Ethernet, и для первых систем, таких, как системы пионеров этого рынка, Simplivity и Nutanix, межузловая локальность считалось важнейшим свойством. Эти решения реализовывали функцию предпочтительной записи на локальные устройства, предпочтительного чтения с локального устройства и автоматической перестройки всей сети хранения при живой миграции виртуальной машины на другой узел.

В программно-определяемых сетях хранения (software-defined storage, SDS) наилучшего эффекта удалось добиться при их совместной эксплуатации с платформами виртуализации, когда блоки томов виртуальных машин располагались по возможности на тех же узлах, где запущены эти машины, с чтением предпочтительно с локального устройства хранения. Одной из исторически первых SDS, реализовавших межузловую локальность, была Parallels Storage (ныне Virtuozzo Storage). Она-то и легла в основу программно-определяемой сети гиперконвергентного комплекса «Скала-Р» (компонент «Р-Хранилище»).

Но с переходом на 10-гигабитные сети многие производители гиперконвергентных систем, таких, как Maxta, Atlantis, системы на основе VMWare vSAN и др., отказались от реализации межузловой локальности. Большая часть существующих SDS, включая Microsoft S2D, Dell-EMC ScaleIO, RedHat CephFS и RedHat GlusterFS, вовсе не реализуют межузловую локальность, а VMWare реализует локальность в vSAN, как локальный кэш «горячих» данных и отрицает необходимость в межузловой локальности. Это мотивируется низкими задержками в современной 10-гигабитной сети и потенциальным ущербом сбалансированности системы хранения при соблюдении правил межузловой локальности.

При этом большинство гиперконвергентных систем и в настоящее время поставляются без сетевого решения! С нашей стороны мы сделали сетевое решение Mellanox для сетей RoCE, имеющее пропускную способность 56 Гбит/с и обеспечивающих функции разгрузки центральных процессоров (CPU offload), интегрированной частью комплекса «Скала-Р». Дублированные коммутаторы обеспечивают надежность, их свойства обеспечивают уверенный запас по пропускной способности даже в сценариях с массовой миграцией виртуальных машин, выход из строя даже целого коммутатора не приводит к снижению доступности.

Что же касается межузловой локальности, то она, как было отмечено, унаследована «Скалой-Р» из реализации Parallels Storage: блоки данных виртуальной машины пишутся предпочтительно на локальные устройства, и чтение осуществляется локально. Но значимость этого свойства для «Скалы-Р» невелика – используемое нами сетевое решение практически нивелирует сетевой фактор в вопросах производительности.

Реализована в «Скале-Р» и функция перестройки хранилища с учетом локальности, но она не запускается автоматически при живой миграции машин. «Автоматику» было бы несложно реализовать, но анализ опыта эксплуатации системы не подтвердил целесообразности такого решения. Например, в ситуации плановой или аварийной перезагрузки одного из узлов (что со «Скалой-Р» происходит заметно реже, чем в случае Nutanix и Simplivity), которая занимает 1–2 минуты, автоматическая перестройка хранилища не будет иметь никакого смысла и при этом повлечет заметное снижение производительности. Если же виртуальная машина после миграции останется на новом узле, ее новые данные в любом случае будут записываться на локальные устройства. Так или иначе, системный администратор всегда располагает полной информацией для принятия решения о повторной миграции машин, перестройке сети хранения или промежуточных мерах.

Заключение

Итак, насколько эффективна локальности данных для гиперконвергентных систем? В общем случае межузловая локальность полезна в программно-определяемых сетях хранения, поскольку позволяет уменьшить межсетевое взаимодействие, снизить нагрузку на сеть и повысить общую производительность системы. Но функция автоматической перестройки хранилища при миграции виртуальных машин не только не является необходимой – в условиях относительно крупных виртуальных машин она скорее вредна.

В целом же межузловая локальность не имеет отношения к готовности к нагрузкам и эксплуатации в масштабах предприятия (в терминах RAS). Это лишь дополнительное свойство, и чем выше производительность сетевых решений, тем ниже его ценность.