Устойчивость данных в Ceph или Gluster
Скажем, меня больше всего беспокоит защита моих данных от физического сбоя жесткого диска и компьютера, к которому он напрямую подключается.
RAID1 и RAID5 Я понимаю. Они обеспечивают защиту от потери данных из-за проблем с оборудованием.
Как Gluster и Ceph защищают от одних и тех же проблем? Чтобы не усложнять задачу, исключим ответы на облака и репликацию.
Делает ли Gluster или Ceph что-то вроде SW raid, или я все еще буду использовать HW raid?
ОБНОВЛЕНИЕ: Предположим, у меня есть три + сервера, каждый с одним физически подключенным HD . Затем, если я превращу эти три дисковых пространства в пространство Gluster или Ceph. Что произойдет, если выйдет из строя один физический диск. Потеряю ли я весь кластер, часть кластера или он просто продолжает работать?
Целью RAID не является защита от потери данных из-за аппаратного сбоя, случайного удаления или чего-либо еще. Это для увеличения производительности (RAID0, RAID0 + 1) и / или предотвращения простоев (RAID1, RAID5, RAID6). Если вы хотите предотвратить потерю данных,тогда вам нужно решение для резервного копирования. Желательно, чтобы один хранится на месте, а другой - за его пределами.
Вы запросили, чтобы ответы по облаку и репликации не предоставлялись, но это единственный способ предотвратить потерю данных. RAID1 и RAID5 защитят в случае отказа одного диска, а RAID6 позволит двум дискам выйти из строя, но ни один из них не защитит от повреждения данных, случайного удаления или злонамеренных действий. Если эти данные важны, тогда вам понадобятся те вещи, которые вы просили не предоставить.
Общая суть этого вопроса: «Как многоузловые кластеры хранения связаны с такими концепциями, как RAID?»
Ответ в том, что они в некоторой степени связаны. RAID-массив предназначен для репликации и / или распределения данных по доменам отказа. В случае RAID эти домены отказа представляют собой отдельные диски. Потеря диска в массиве, нацеленном на избыточность, не означает потерю данных (надежность) или доступ к этим данным (доступность).
Кластеры хранения с несколькими узлами можно рассматривать очень похожим образом, с возможность адресации целых узлов или групп узлов как доменов отказа, а не только дисков или групп дисков в одном узле. Данные могут быть распределены между узлами, не заботясь о репликации, или данные могут быть реплицированы между двумя или потенциально более узлами (или группами узлов).
Как предмет, кластеризация хранилища НАМНОГО сложнее, чем такие концепции, как RAID, и рекламное объявление Я уже писал выше, близок к концу их сходство. Они не являются взаимоисключающими технологиями и могут быть смешанными - можно выбрать использование RAID в узлах кластера хранения или даже создать RAID-массивы многих кластерных целевых устройств хранения. Опять же, это сложно - настолько сложно на самом деле, что очень легко создавать ужасные кластеры, которые вызывают больше проблем, чем решают.
Я бы рекомендовал убедиться, что каждый хорошо разбирается в данной технологии кластеризации хранилищ очень , прежде чем пытаться использовать его в серьезном качестве. К счастью, все Ceph, Gluster, DRBD и родственные технологии имеют открытый исходный код и доступны для изучения так же открыто.
Некоторые конфигурации RAID предотвращают потерю данных из-за проблем с оборудованием - один диск может выйти из строя, в то время как на другом все еще доступна копия данных. Вместо этого другие конфигурации RAID повышают производительность.
Ceph реплицирует данные на уровне объекта (уровень RADOS), сохраняя несколько копий данных на отдельных дисках, расположенных на разных хостах (обычно используются три копии), или, в качестве альтернативы, , данные разбиваются на блоки с кодом стирания - это будет похоже на схему четности RAID в вашей ментальной модели.
Это данные отказоустойчивость ,и измеряется в том, сколько хостов или дисков может потерять кластер, при этом гарантируя отсутствие потери данных. В пулах хранения реплики 3 вы можете потерять два диска одновременно и не потерять данные. Если события дают кластеру время между двумя отказами дисков в моем примере, он самовосстанавливается и копирует данные, затронутые первым отказом, возвращаясь к избыточности реплики 3.
Давайте посмотрим на ваш запрос для трех хостов с одним жестким диском. диск каждый. В этой конфигурации пул реплики-3 Ceph может потерять два хоста и по-прежнему сделать данные доступными, кластер продолжит работу. После первого сбоя кластер продолжит работу и предупредит администратора, что отказоустойчивость снизилась с двух сбоев до одного. После второго сбоя, когда останется только одна копия данных, кластер продолжит обслуживание данных, но переключится в режим только для чтения и заставит администратора устранить потерю отказоустойчивости. Отказоустойчивость EC зависит от выбранной схемы кодирования, но в вашем примере просто не будет использовать пул с стираемым кодом всего с тремя хостами.
Как правило, программно-определяемое хранилище, такое как Ceph, имеет смысл только при определенном масштабе данных. Традиционно я рекомендовал половину петабайта или 10 хостов с 12 или 24 дисками каждый в качестве минимального порога. Недавние улучшения UX в самоуправлении и автоматизации делают 5 хостов разумным минимальным порогом.
Ни Ceph, ни репликация RAID не являются решением для резервного копирования - это сценарий восстановления данных, а не сценарий обеспечения отказоустойчивости. Но в то время как репликация на основе объектов Ceph масштабируется практически бесконечно, репликация на основе дисков RAID не может масштабироваться очень далеко.