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