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