Попытка спроектировать хранилище на 3-10 Пбайт (содержащего 3000-10000 жёстких дисков) продемонстрировала дефект в дизайне OpenStack Swift. Как оказалось OpenStack Swift (возможно и другие подобные системы) не масштабируется бесконечно и расточительно использует оборудование. При использовании большого количества дисков (больше 3000) потеря данных в практически неизбежна.
Ребята из Openstack предлагают создавать 3 копии (по умолчанию). Откуда взята такая цифра? Почему не 2, 4 или 5: Никакой методики расчёта надёжности они не предоставляют.
В общем случае (3-2-1 rule) 3 копии используют учитывая следующие обстоятельства:
1. Первая копия (рабочая) строится на железе с высокой производительностью. Это основное хранилище. Большая часть операций приходится на рабочую копию.
2. Вторая копия географически разделена с первой. Железо не столь производительно. Данные реплицируются асинхронно. В случае вывода из строя основного хранилища вторая копия берет на себя нагрузку.
3. Третья копия защищает от глупых ошибок (её должны делать другие администраторы, использовать отличное ПО и железо от первых 2х копий).
То есть выполняется принцип «не класть все яйца в одну корзину».
В случае же Swift — все данные лежат в одном месте, используется одинаковое ПО. Тем не менее акцент ставится именно на 3 копии (варианты с другим количеством они не тестировали).
Если у нас 3 копий в хранилище (избыточность 200%), это означает что можно потерять 2 диска — при этом данные сохранятся гарантировано. В случае малого количества дисков это единственная возможная схема построения. Но распространить её на большое количество дисков — глупая трата ресурсов. Должны применяться более продвинутые методы (коррекция ошибок), нежели простое копирование.
Схема двойной чётности (RAID6) также защищает от смерти 2х дисков, при этом избыточность лежит в пределах 20-40%. Есть и другие алгоритмы избыточности при хранении, но OpenStack почему-то не использует их.
Допустим в хранилище 3000 дисков. Согласно статистики от Google, за год эксплуатации выйдет из строя 1-5% дисков. Событие выхода из строя 3х дисков одновременно становится обыденным, и должно случаться несколько раз в год (3-6 раз, расчёты опускаю). Если все копии разбросаны по дискам случайно, как это сделано в Swift, то наверняка какой-то из файлов окажется в трёх умерших дисках.
Увеличивать количество копий выглядит абсурдным. 300%? 400%?
Данная компания более продуманно подошла к построению хранилищ, и предлагает проект аж на 10EB с использование кодов Рида-Соломона для надёжного хранения. Их избыточность составляет 35% — и это при 4 500 000 дисках!
— OpenStack пытается раскрутиться через громкое слово «облако» и поддержке «Rackspace and NASA». Другие знаменитые компании подключаются к этому проекту. Хотя всё может оказаться не так радужно. Бесконечной масштабируемости в настоящее время нет.
— Три и более копий могут использоваться для увеличения производительности хранилища. Так Facebook использует HDFS и хранилищем в 30 Пб. Однако, кто огласит информацию о потерянных данных?!
— CleverSafe говорит что их код GPL (4 года назад). Может у кого-нибудь остались исходники?
Более детальные расчёты в моей статье на английском.
Ребята из Openstack предлагают создавать 3 копии (по умолчанию). Откуда взята такая цифра? Почему не 2, 4 или 5: Никакой методики расчёта надёжности они не предоставляют.
Откуда пошла идея 3х копий
В общем случае (3-2-1 rule) 3 копии используют учитывая следующие обстоятельства:
1. Первая копия (рабочая) строится на железе с высокой производительностью. Это основное хранилище. Большая часть операций приходится на рабочую копию.
2. Вторая копия географически разделена с первой. Железо не столь производительно. Данные реплицируются асинхронно. В случае вывода из строя основного хранилища вторая копия берет на себя нагрузку.
3. Третья копия защищает от глупых ошибок (её должны делать другие администраторы, использовать отличное ПО и железо от первых 2х копий).
То есть выполняется принцип «не класть все яйца в одну корзину».
В случае же Swift — все данные лежат в одном месте, используется одинаковое ПО. Тем не менее акцент ставится именно на 3 копии (варианты с другим количеством они не тестировали).
Парадокс копий
Если у нас 3 копий в хранилище (избыточность 200%), это означает что можно потерять 2 диска — при этом данные сохранятся гарантировано. В случае малого количества дисков это единственная возможная схема построения. Но распространить её на большое количество дисков — глупая трата ресурсов. Должны применяться более продвинутые методы (коррекция ошибок), нежели простое копирование.
Схема двойной чётности (RAID6) также защищает от смерти 2х дисков, при этом избыточность лежит в пределах 20-40%. Есть и другие алгоритмы избыточности при хранении, но OpenStack почему-то не использует их.
Допустим в хранилище 3000 дисков. Согласно статистики от Google, за год эксплуатации выйдет из строя 1-5% дисков. Событие выхода из строя 3х дисков одновременно становится обыденным, и должно случаться несколько раз в год (3-6 раз, расчёты опускаю). Если все копии разбросаны по дискам случайно, как это сделано в Swift, то наверняка какой-то из файлов окажется в трёх умерших дисках.
Увеличивать количество копий выглядит абсурдным. 300%? 400%?
CleverSafe
Данная компания более продуманно подошла к построению хранилищ, и предлагает проект аж на 10EB с использование кодов Рида-Соломона для надёжного хранения. Их избыточность составляет 35% — и это при 4 500 000 дисках!
В сухом остатке
— OpenStack пытается раскрутиться через громкое слово «облако» и поддержке «Rackspace and NASA». Другие знаменитые компании подключаются к этому проекту. Хотя всё может оказаться не так радужно. Бесконечной масштабируемости в настоящее время нет.
— Три и более копий могут использоваться для увеличения производительности хранилища. Так Facebook использует HDFS и хранилищем в 30 Пб. Однако, кто огласит информацию о потерянных данных?!
— CleverSafe говорит что их код GPL (4 года назад). Может у кого-нибудь остались исходники?
Более детальные расчёты в моей статье на английском.