Из красиво описанных есть пример конторы Continuum health partners, они как раз начинали с объединения несовметсимых стораджей, и плавно доросли до 2х петабайт.
Можно посмотреть или прочитать.
Но там про сам зоопарк разве что идея, деталей нет.
На практике же зоопарк в проектах виртуализации встречается регулярно. Из недавнего, казалось бы, простая задача, зеркалировать данные в формально «гомогенной» среде между трипаром и ивой, везде FC плюс имеются N штук MSA и пара P2000, нужно распределить коробки по 2-м площадкам и зеркалировать данные. Понятно, что SSV не единственное решение, но закрывает вопрос легко, добавляется пара не менее «гомогенных» серверов, на них Datacore и полетели, причем кэш и возможность подкинуть в сам сервер SSD или лучше PCI-SSD уравновешивают производительность площадок. Тут формально не зоопарк, а больше сложности внутри семейства, но подход абсолютно тот же.
По лицензированию, учитывается каждый узел, к нему объем, который нужно виртуализировать, плюс отдельно опции, например, FC и CDP входят не во все базовые лицензии. По небольшим одиноким СХД — тут не поспоришь, хорошее исключение — это высоконагруженные системы с раскладом: много иопсов — мало объема, тут обычный сервак в PCI-SSD картой и датакором прям поборются.
Что касается пропускной способности и задержки, то со стороны системы временных ограничений для синхронной репликации кэшей нет, реальные требования диктуются хостом, т.е. сколько приложение готово ждать ответа и именно эти требования должны быть основой для сайзинга, а именно — какие использовать тип протокола, тип HBA и максимально возможное расстояние между ЦОДами (например, оптоволокно дает 5 мкс задержки на 1 километр).
Сам Datacore — low latency app, т.е. значимых задержек не вносит. Лучшее что видел мой иометер это 0,14 милисекунд с синхронной репликацией.
К сожалению, даже самые невероятные аварии случаются и уносят миллионы. Примеров десятки реально, начиная от двух строек с забитыми сваями в европейском магистральном кольце с разрывом в 2 часа.
Спасибо за вопрос. Если виртуальный диск живет на двух нодах, запитанных от одного источника, то им точно нужен ИБП, без вариантов, в кэше никаких батареек нет, т.к. это самая обычная RAM x86. ИБП рекомендуется пользовать дружащий с виндой, чтобы датакор знал в каком он состоянии, т.е. на батарейке — выключаем кэш на запись, мало батарейки — нода просит соседку включить журнал рассинхронизации, а сама выключается.
В нашем случае (Задача 1) есть диски, как живущие в одном ЦОД, (условно vDisk1 на картинке) так и аля «метрокластре», т.е. одна копия в ЦОД, вторая в РЦОД (vDisk2 и vDisk3).
Формальное ограничение для коммерческих пользователей (т.е. не требует доп. манипуляций) это 64 хоста и 64PB, соответственно.
Между ДЦ растягивается, такой пример как раз описан в статье (Задача №1), реплицировать м/у площадками можно синхронно, можно асинхронно.
Падение четверти/трети или даже половины узлов никак не скажется на доступности сервиса, но если покрашились строго половинки от синхронных копий, например отрубилась связь с площадкой. Дело в том, что виртуальный диск, который презентует SSV живет строго в двух синхронных физических копиях. Если одну мы потеряли, то хост этого не замечает, если обе, то чуда не происходит и диск более недоступен.
То есть, если по феншую раскидать вирт. диски по хостам, то вероятность потерять сервис минимальна.
Да, базы и прочая OLTP-нагрузка переваривается хорошо. Тьиринг как раз помогает держать систему в нужном тонусе.
Если вы пишите, что производительность критична, то выставляем диску соответсвующий профиль и тьиринг будет держать данные на нужных носителях. Или если по каким-либо причинам вы не хотите привязывать диск к определенному профилю на помощь приходит механизм упреждающего чтения, который работает по следующей схеме:
— если чтение последовательное или укладывается в логику упреждающего чтения, тогда данные очень быстро читаются из кэша
— если чтение блоков носит абсолютно случайный характер, что наименее вероятно в сценарии работы с базами данных, тогда данные действительно будут читаться с того носителя на котором они размещены.
Для определения температуры данных используется функционал под названием data tiering. Вещь сейчас достаточно известная и распространенная. Tiering делается на блочном уровне. Блоки данных, к которым происходит наиболее частые обращения, размещаются на более быстрых носителях, а те блоки, к которым мало обращений, или их вовсе нет, размещаются на более медленных носителях. Плюс есть технологии, которые позволяют подгрузить сразу в кэш блоки, к которым еще не обращались, но вероятнее всего в скором времени обратятся.
Конкретно в Datacore Tiering работает на блочном уровне по очень простой схеме: SSV оценивает статистику обращения к конкретному блоку, сравнивает с историей, и если блок стал популярнее, то переносит его на быстрые носители. Если наоборот, то на медленные. Оценка и перенос происходит раз в секунду, 30 секунд или минуту. При этом перенос блоков является «неприоритетной» задачей, сначала приложение убедится что у него достаточно ресурсов для чтения и записи, и только потом осуществит перенос. При этом уровней аж 15 штук. Соответственно, и настройки могут быть очень гибкими.
Я попробовал уточнить у наших юристов, чтобы не быть голословным. Деталей довольно много, говорят, надо решать по ситуации, поэтому, собственно, рекомендаций даже примерно дать не могу, увы.
Поддержку, видимо, предполагается закупать через «прокси-структуры» вроде интеграторов или дочерние компании. Но пока не до конца понятна правоприменительная практика.
Если детальнее.
Текущее сапописное ПО, написанное под винду достаточно давно, действительно можно в приемлемые сроки и за приемлемые деньги портировать под линукс платформу. Подобный софт встречается у многих. И обычно это софт, поддерживающий основные бизнес-процессы компаний.
Приемлемые деньги — это значит меньше, чем писать заново под линукс с нуля. В реальном исчислении может быть и недешево. Речь не о скриптах, а именно о приложениях.
Унификация — это один из наших приоритетов. Нам бы тоже хотелось брать готовые модули и из них создавать полноценные решения. С одной стороны.
С другой «а вот тут мы один модуль просто допишем» — значит, что если производители коммерческого софта сейчас вообще то неохотно идут на уникальные доработки, нужные заказчику, то мы с использованием СПО можем их сделать. Для многих крупных заказчиков — это совсем не минус. Это преимущество. Поскольку помогает им организовать работу так как нужно и в данный момент. А не ждать релиза вендора, который выйдет через год, а может и вообще не выйдет.
Мы зарабатываем на решении задач заказчиков, а не на использовании ПО. Мне хочется верить, что открытое ПО разрабатывается для использования по назначению. И ставить барьер «зарабатываешь — плати» неправильно. Мы не спонсируем проекты, но уже не первый раз разработчики решений получают существенные суммы за поддержку. К примеру, для одной из ОС в рамках недавнего проекта эта сумма составила их полугодовой бюджет.
У нас чаще всего крупный заказчик использует свою собственную систему документооборота, плюс мы ставим LibreOffice и шаблоны для подготовки быстрой отчетности. Крупных проблем не было, но есть отдельные заказчики, у кого много макросов, либо есть документы со сложной вёрсткой — там нужно переделывать. Обычные же пользователи не всегда осознают, что что-то вообще поменялось.
KVM нам как-то чаще попадался. К тому же у Xen есть архитектурная проблема — доп.звено в виде гипервизора, работающего в собственном контексте, соответственно, его производительность на больших нагрузках меньше.
Про Ubuntu: Это система в первую очередь для десктопов, в силу специфики комьюнити.
Debian: очень медленно обновляется. И не похоже, что его сопровождать проще и дешевле, чем centos.
Да, там была проблема с пробросом Kerberos ticket, просто не работало в определённых условиях. Наш инженер позвонил прямо разработчику из Цитрикса, который сразу всё понял и устранил проблему.
Официальный ответ коллеги из маркетинга: «Действительно до недавнего времени акцент был на общеизвестных вендорах. Это связано с тем, что ppen-sourse решения были достаточно незрелыми, чтобы можно было их часто внедрять и говорить о них, сейчас же тенденции меняются, в том числе получая подпитку политикой, завязанной на санкции. Open-sourse решения стали более зрелыми, достойными соперниками. Потому все больше open-sourse вендоров появляются в портфеле решений КРОК в разделе Партнеры.
И мы в процессе создания информационных материалов, листовок и Success Story, где расскажем о самих интересных проектах.»
Да, действительно, можно реализовать такую систему на Proxmox, например. Возможность работы высоконагруженной БД будет зависеть, тем не менее, от правильного сайзинга серверов. Какие поставить диски, например. Обязательно нужно предусмотреть SSD для журналов и правильно выбрать дисковый контроллер в серверы (как показывает практика, не все они одинаково хороши). А процессоры сейчас уже настолько производительные, что вряд ли станут узким местом.
Можно посмотреть или прочитать.
Но там про сам зоопарк разве что идея, деталей нет.
На практике же зоопарк в проектах виртуализации встречается регулярно. Из недавнего, казалось бы, простая задача, зеркалировать данные в формально «гомогенной» среде между трипаром и ивой, везде FC плюс имеются N штук MSA и пара P2000, нужно распределить коробки по 2-м площадкам и зеркалировать данные. Понятно, что SSV не единственное решение, но закрывает вопрос легко, добавляется пара не менее «гомогенных» серверов, на них Datacore и полетели, причем кэш и возможность подкинуть в сам сервер SSD или лучше PCI-SSD уравновешивают производительность площадок. Тут формально не зоопарк, а больше сложности внутри семейства, но подход абсолютно тот же.
Что касается пропускной способности и задержки, то со стороны системы временных ограничений для синхронной репликации кэшей нет, реальные требования диктуются хостом, т.е. сколько приложение готово ждать ответа и именно эти требования должны быть основой для сайзинга, а именно — какие использовать тип протокола, тип HBA и максимально возможное расстояние между ЦОДами (например, оптоволокно дает 5 мкс задержки на 1 километр).
Сам Datacore — low latency app, т.е. значимых задержек не вносит. Лучшее что видел мой иометер это 0,14 милисекунд с синхронной репликацией.
В нашем случае (Задача 1) есть диски, как живущие в одном ЦОД, (условно vDisk1 на картинке) так и аля «метрокластре», т.е. одна копия в ЦОД, вторая в РЦОД (vDisk2 и vDisk3).
ScaleIO — так и есть, спасибо за уточнение.
Между ДЦ растягивается, такой пример как раз описан в статье (Задача №1), реплицировать м/у площадками можно синхронно, можно асинхронно.
Падение четверти/трети или даже половины узлов никак не скажется на доступности сервиса, но если покрашились строго половинки от синхронных копий, например отрубилась связь с площадкой. Дело в том, что виртуальный диск, который презентует SSV живет строго в двух синхронных физических копиях. Если одну мы потеряли, то хост этого не замечает, если обе, то чуда не происходит и диск более недоступен.
То есть, если по феншую раскидать вирт. диски по хостам, то вероятность потерять сервис минимальна.
Если вы пишите, что производительность критична, то выставляем диску соответсвующий профиль и тьиринг будет держать данные на нужных носителях. Или если по каким-либо причинам вы не хотите привязывать диск к определенному профилю на помощь приходит механизм упреждающего чтения, который работает по следующей схеме:
— если чтение последовательное или укладывается в логику упреждающего чтения, тогда данные очень быстро читаются из кэша
— если чтение блоков носит абсолютно случайный характер, что наименее вероятно в сценарии работы с базами данных, тогда данные действительно будут читаться с того носителя на котором они размещены.
Конкретно в Datacore Tiering работает на блочном уровне по очень простой схеме: SSV оценивает статистику обращения к конкретному блоку, сравнивает с историей, и если блок стал популярнее, то переносит его на быстрые носители. Если наоборот, то на медленные. Оценка и перенос происходит раз в секунду, 30 секунд или минуту. При этом перенос блоков является «неприоритетной» задачей, сначала приложение убедится что у него достаточно ресурсов для чтения и записи, и только потом осуществит перенос. При этом уровней аж 15 штук. Соответственно, и настройки могут быть очень гибкими.
Текущее сапописное ПО, написанное под винду достаточно давно, действительно можно в приемлемые сроки и за приемлемые деньги портировать под линукс платформу. Подобный софт встречается у многих. И обычно это софт, поддерживающий основные бизнес-процессы компаний.
Приемлемые деньги — это значит меньше, чем писать заново под линукс с нуля. В реальном исчислении может быть и недешево. Речь не о скриптах, а именно о приложениях.
С другой «а вот тут мы один модуль просто допишем» — значит, что если производители коммерческого софта сейчас вообще то неохотно идут на уникальные доработки, нужные заказчику, то мы с использованием СПО можем их сделать. Для многих крупных заказчиков — это совсем не минус. Это преимущество. Поскольку помогает им организовать работу так как нужно и в данный момент. А не ждать релиза вендора, который выйдет через год, а может и вообще не выйдет.
Debian: очень медленно обновляется. И не похоже, что его сопровождать проще и дешевле, чем centos.
И мы в процессе создания информационных материалов, листовок и Success Story, где расскажем о самих интересных проектах.»