Уважаемый ksr123, спасибо за вопрос. Ответ на него как раз и содержится в анонсированном вебинаре «Стимулирование инноваций и инсайты по требованию». Приглашем Вас послушать вебинар и узнать, при чём тут HPE Cray, какие ещё компоненты HPE Cray возможно разместить в ЦОДе прямо сейчас и многое другое.
Теперь ясно, какой отказ имелся в виду изначально…
В случае кластера из 3 узлов А, Б, В и разрыва сети на сегменты (А) и (Б, В) произойдет следующее:
• модификация реплик обслуживаемых узлом А прекратится, т.к. активные реплики на узлах (Б, В) станут недоступны узлу А;
• успешная модификация всех в данный момент логически активных реплик является необходимым условием успешного завершения операции записи. Модификации реплик блоков отдельно взятого тома данных проходят через и управляются одним узлом. Поэтому параллельные модификации в части кластера (Б, В) или split brain невозможны в принципе и консистентность гарантирована;
• узел А будет выведен из кластера, новый список активных реплик будет состоять из (Б, В);
• клиентские точки соединений, управляемые до этого узлом А, будут подняты на узлах Б и В (failover).
Длительность описанного выше полностью автоматического процесса имеет секундный порядок. Это стандартный тест-кейс PoC.
В общем и целом теорема CAP применима для всех и для Datera тоже. В Datera реализован эластичный и поэтому живучий сервис управления кластером, а также высокий приоритет отдаётся скорости и надёжности определения ошибок и их автоматической отработки. Если добавить конкретно по сети, мы рекомендуем архитектуру с резервированием для минимизации вероятности подобных сценариев, приглашаем пользователей проводить тесты с любыми отказами и их комбинацией во время фазы pre-sales. Это само собой разумеется.
Евгений, раз вас так интересует данная тема, пожалуйста, направьте свои контакты в личку. Обсудим интересующие Вас детали.
Механизм синхронизации реплик Datera поддерживает консистентность данных в Read/Write режиме и при одной сохранившейся реплике. На практике случаи с одной сохранившейся репликой из трёх при одновременном отказе двух узлов случаются, это заложено на уровне базовой архитектуры, всё откатано в production, и проблем split brain не возникает.
При возобновлении работы вышедших из строя узлов происходит автоматическая синхронизация устаревших реплик, до этого момента устаревшие реплики не будут использоваться при обслуживании запросов. Можно ещё заметить, что модификации (операции записи) в наборе реплик, формирующие отдельный том или volume, контролируются одной софтверной компонентой на одном узле с возможностью failover в случае выхода узла из строя.
2. Вопрос не совсем понятен. Что значит «выход 50+%»? Если имеется в виду выход из строя 50%+ количества узлов кластера, то здесь к Datera применяются те же правила, что и к любым другим распределённым системам. Например, если в кластере 18 узлов по 6 узлов в каждой стойке (3 стойки) выйдет из строя 2 стойки (12 из 18 узлов – 2/3 ёмкости), при тройной репликации все данные будут доступны, но нагрузка будет обеспечиваться оставшимися 6 узлами. Естественно, на время простоя 2 стоек это практически может означать снижение производительности, а если кластер находится под минимальной нагрузкой, то такой сбой может пройти вообще незаметно. Всё зависит от конкретных условий, но поведение прогнозируемо в зависимости от того, как конкретно используется кластер: какой-то «непонятности» здесь нет.
Разгрузка кластера по стойкам и их количество диктуется требованиями к надёжности системы. В одной крупной компании, глобальном обработчике критических транзакций, мы разносили распределённые системы как правило по 6 автономным зонам ЦОД. Выход из строя одной зоны означал потерю 1/6 ёмкости. Тестовые системы, внутренние системы с меньшими требованиями к надежности можно разносить по 3 зонам и так далее, вплоть до одной стойки.
Эти правила применимы практически к любым распределённым системам. Это означает в том числе то, что при планировании архитектуры с клаcтерами Datera могут быть использованы те же принципы и методы, что и для «обычных» распределённых приложений, каких-то специальных знаний не требуется. Это же касается и планирования кластера с одной стойкой.
Не думаю, что Вы оценили бы сухой DataSheet. Про S3 как-нибудь расскажем, благо есть наработанный опыт внедрения объектных хранилищ, в том числе в РФ. Но упор сделаем на коммерческий продукт типа Scality. Будете читать? :)
В случае кластера из 3 узлов А, Б, В и разрыва сети на сегменты (А) и (Б, В) произойдет следующее:
• модификация реплик обслуживаемых узлом А прекратится, т.к. активные реплики на узлах (Б, В) станут недоступны узлу А;
• успешная модификация всех в данный момент логически активных реплик является необходимым условием успешного завершения операции записи. Модификации реплик блоков отдельно взятого тома данных проходят через и управляются одним узлом. Поэтому параллельные модификации в части кластера (Б, В) или split brain невозможны в принципе и консистентность гарантирована;
• узел А будет выведен из кластера, новый список активных реплик будет состоять из (Б, В);
• клиентские точки соединений, управляемые до этого узлом А, будут подняты на узлах Б и В (failover).
Длительность описанного выше полностью автоматического процесса имеет секундный порядок. Это стандартный тест-кейс PoC.
В общем и целом теорема CAP применима для всех и для Datera тоже. В Datera реализован эластичный и поэтому живучий сервис управления кластером, а также высокий приоритет отдаётся скорости и надёжности определения ошибок и их автоматической отработки. Если добавить конкретно по сети, мы рекомендуем архитектуру с резервированием для минимизации вероятности подобных сценариев, приглашаем пользователей проводить тесты с любыми отказами и их комбинацией во время фазы pre-sales. Это само собой разумеется.
Евгений, раз вас так интересует данная тема, пожалуйста, направьте свои контакты в личку. Обсудим интересующие Вас детали.
При возобновлении работы вышедших из строя узлов происходит автоматическая синхронизация устаревших реплик, до этого момента устаревшие реплики не будут использоваться при обслуживании запросов. Можно ещё заметить, что модификации (операции записи) в наборе реплик, формирующие отдельный том или volume, контролируются одной софтверной компонентой на одном узле с возможностью failover в случае выхода узла из строя.
2. Вопрос не совсем понятен. Что значит «выход 50+%»? Если имеется в виду выход из строя 50%+ количества узлов кластера, то здесь к Datera применяются те же правила, что и к любым другим распределённым системам. Например, если в кластере 18 узлов по 6 узлов в каждой стойке (3 стойки) выйдет из строя 2 стойки (12 из 18 узлов – 2/3 ёмкости), при тройной репликации все данные будут доступны, но нагрузка будет обеспечиваться оставшимися 6 узлами. Естественно, на время простоя 2 стоек это практически может означать снижение производительности, а если кластер находится под минимальной нагрузкой, то такой сбой может пройти вообще незаметно. Всё зависит от конкретных условий, но поведение прогнозируемо в зависимости от того, как конкретно используется кластер: какой-то «непонятности» здесь нет.
Разгрузка кластера по стойкам и их количество диктуется требованиями к надёжности системы. В одной крупной компании, глобальном обработчике критических транзакций, мы разносили распределённые системы как правило по 6 автономным зонам ЦОД. Выход из строя одной зоны означал потерю 1/6 ёмкости. Тестовые системы, внутренние системы с меньшими требованиями к надежности можно разносить по 3 зонам и так далее, вплоть до одной стойки.
Эти правила применимы практически к любым распределённым системам. Это означает в том числе то, что при планировании архитектуры с клаcтерами Datera могут быть использованы те же принципы и методы, что и для «обычных» распределённых приложений, каких-то специальных знаний не требуется. Это же касается и планирования кластера с одной стойкой.