Как стать автором
Обновить

OpenStack Swift. Не все три копии одинаково полезные

Время на прочтение2 мин
Количество просмотров6.5K
Попытка спроектировать хранилище на 3-10 Пбайт (содержащего 3000-10000 жёстких дисков) продемонстрировала дефект в дизайне OpenStack Swift. Как оказалось OpenStack Swift (возможно и другие подобные системы) не масштабируется бесконечно и расточительно использует оборудование. При использовании большого количества дисков (больше 3000) потеря данных в практически неизбежна.

Ребята из 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 года назад). Может у кого-нибудь остались исходники?

Более детальные расчёты в моей статье на английском.
Теги:
Хабы:
Всего голосов 24: ↑17 и ↓7+10
Комментарии23

Публикации

Истории

Ближайшие события

7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань