Вопрос: Общий диск в современном дата-центре (SAN, виртуализация и т. Д.)


Я разработчик ... ступаю сюда по чужой местности. Прошу простить любую наивность.

Я работаю над приложением, которое хранит данные как в базе данных, так и в файловой системе.

Контекст: кластеризация и сетевые ресурсы

Раньше, когда мы запускали кластерное приложение (т. Е. Несколько серверов приложений, выходящих из данных), мы обработали файловую систему следующим образом:

  • Узел A: разделяет «каталог данных» (через samba или nfs)
  • Узлы B, C, D и т. Д.: Монтирует «сетевой ресурс» и использует его в своем «каталоге данных»,

Уменьшенная «скорость диска» для узлов B, C, D была субоптимальной, но не большой проблемой.

Также обратите внимание: Приложение использует свой собственный механизм блокировки файлов. Одновременные записи не являются проблемой.

Вопросы

  • Таким образом, в современном дата-центре волоконно-оптический канал соединяет серверы с SANS, каков наилучший способ обмена «куском диска» среди нескольких серверов?

  • Широко используется такой «дисковый обмен»?

  • Любые проблемы, связанные с ОС («работает на Linux, но недоступно в Windows»)

  • Какие-либо оговорки? Трудно настроить, ненадежны и т. Д.?

Я слышал много «мы не можем этого сделать» от наших системных администраторов .., которые, наконец, когда я спросил более подробно, они сказали «хорошо, технически это возможно, но мы не так делаем это здесь»,

заранее спасибо,

Обновление: Спасибо за ответы. (Все они были хороши: я должен был выбрать один из них. Извините, если он не был вашим) Так же, как я ожидал (в некоторой степени): мои надежды на то, что вы можете просто подключить NTFS или XFS или любую «обычную» файловую систему к тому же «hunk» «диска» оказалось наивным. Клеточная файловая система - это билет. И причудливые файловые системы не входят в главные приоритеты нашей хостинговой команды).


6
2017-09-24 19:58


Источник


SAN упрощают подключение нескольких блоков к блочному устройству. Однако... это не означает, что вы можете просто подключить кучу серверов к файловой системе ext4 и ожидать, что все будет работать. Это не так. Если вам нужен параллельный доступ, вам нужна файловая система кластера, или вам нужно сделать что-то вроде того, что вы делали в прошлом с NFS. - EEAA♦


Ответы:


«Ну, технически это возможно, но мы не так делаем это здесь»

Это звучит очень похоже на то, что я регулярно рассказываю разработчикам;)

С точки зрения операционной деятельности предприятия вы можете как можно больше использовать стандартные повторяемые решения. Если ваше приложение не нуждается в специальном лечении, вы его не получите. Нестандартные решения требуют специализированных навыков, более дорогого или просто большего количества оборудования, и если это «самые современные» неудачи, они также катастрофичны.

Для многих приложений общий доступ к файлам по-прежнему является очень подходящим и широко распространенным решением.

Обычными альтернативными решениями HA для использования файлового ресурса являются:

  • Не храните файлы в файловых системах, но используйте высокодоступную базу данных и вместо этого храните их как BLOB. Очень общий подход. Часто вам уже нужна база данных, и это делает серверы приложений почти безгосударственными, решает множество проблем с блокировкой, репликацией, HA, согласованностью и доступом, перекладывая их на уровень базы данных, где многие из этих проблем - старые новости, хорошо понятые и решена. Это может быть дорогостоящим для поддержания, как только вы достигнете (значительной доли) диапазона петабайт.

  • Правильная кластерная файловая система, которая позволяет одновременному доступу на уровне блоков чтения и записи к вашему совместно используемому хранилищу через Fibre Channel или iSCSI. Массивы для хранения данных, как правило, довольно дорого но это может очень хорошо масштабироваться. Часто файловая система кластера требует (дорогого) лицензирования для каждого узла для программного обеспечения кластера FS. Также довольно распространен в корпоративных средах для специализированных приложений.

  • Используйте хранилище распределенных объектов. Это более открытое решение с аппаратным обеспечением низкого уровня, создающее избыточность и масштабируемость программного обеспечения. Это общий «облачный» подход.


4
2017-09-24 20:49





Если вы подключаете несколько серверов к общему блочному устройству (DASD / SAN), вам по-прежнему необходимо вручную управлять доступом к кускам диска (некоторые базы данных делают это на необработанных дисках, LVM также является опцией, с управляемым доступом к LV) или используйте файловую систему кластера, которая будет управлять одновременным доступом.

Даже с блокировками записи, управляемыми на основе каждого файла, вы можете столкнуться с повреждением FS, иначе, если два хоста попытаются сменить метаданные FS одновременно, на некластерном FS. Ничего современного об этом, BTW, SAN и параллельном доступе к блоку не было с 80-х (если не 70-ые).

Все современные ОС имеют кластерные реализации ФС, а изоляция блоков блоков также возможна, если вы готовы писать все сами, поэтому она очень специфична для того, что вы собираетесь использовать.

EDIT: Ваш «старый» подход к сетевым ресурсам по-прежнему вполне возможен, и файловый сервер позаботится о блокировке файлов, поэтому вам не нужны дополнительные блокирующие механизмы. Если вы не после дополнительной производительности и хотите простого развертывания, это, вероятно, еще самый простой маршрут.

Теперь, если вы хотите поговорить «современно», начните думать об хранении объектов и масштабировать архитектуру для своего приложения.


3
2017-09-24 20:40



+1 для хранения объектов. Похоже, что это ядро ​​вопроса, то есть масштабируемое хранение нерегулярных фрагментов данных. - Dmitri Chubarov


Вам нужно не только общее оборудование, но и кластерная файловая система.

Обычные файловые системы не будут работать - два компьютера в итоге перечеркивают изменения друг друга, и вы получите поврежденную файловую систему.

В кластерных файловых системах компьютеры сообщают друг другу об изменениях, которые они создают, и обрабатывают блокирующие файлы, когда это необходимо, чтобы они не наступали друг на друга.

Некоторые из этих файловых систем относятся к конкретным приложениям - например, VMware имеет VMFS, а Hyper-V имеет общие тома кластера - они отлично работают для хранения виртуальных машин, но не предназначены для общего хранения файлов. Существуют и другие, которые предназначены для хранения любых файлов. Каждый из них имеет различные преимущества и недостатки, поэтому лучше всего зависит от того, что вы делаете с ним. Все они (насколько я знаю) ОС - вы не сможете обмениваться файловой системой между окнами и linux таким образом.

Для некоторых вещей, таких как отказоустойчивость виртуальной машины высокой доступности, вам действительно нужно это. Для приложений, в которых будут работать SMB или NFS, обычно они предпочтительнее - они могут быть немного медленнее, но есть гораздо меньше вещей, которые могут пойти не так, и их легче восстановить, когда они сломаются.


2
2017-09-24 20:40



Сбой при отказе VM в эти дни может быть выполнен с использованием не общего хранилища. Кроме того, кластеризованное FS не является единственным решением для хранилища разделяемых блоков, фактически, такие системы, как VMFS, сильно затрудняются в масштабируемости, в отличие от систем прямого доступа к блокам. Вот почему oVirt может иметь сотни хостов в одном кластере и vsphere только 32 (последний раз, когда я проверил хотя бы, это было всего 32, причем не более 20 рекомендованных) - dyasny