Я разработчик ... ступаю на чужую территорию. Прошу простить за наивность.
Я работаю над приложением, которое хранит данные как в базе данных, так и в файловой системе.
Контекст: кластеризация и сетевые ресурсы
Раньше, когда мы запускали кластерное приложение (то есть несколько серверов приложений, передающих данные), мы обрабатывали файловую систему следующим образом:
Снижение «скорости диска» для узлов B, C, D было неоптимальным, но не было большой проблемой.
Также обратите внимание: Приложение использует собственный механизм блокировки файлов. Одновременная запись не проблема.
Вопросы
Итак, в современном центре обработки данных оптоволоконный канал соединяет серверы с SANS, как лучше всего разделить «кусок диска» между несколькими серверами?
Широко ли используется такое «совместное использование диска»?
Любые проблемы, связанные с ОС ("работает в Linux, но недоступно в Windows")
Есть предостережения? Трудно настроить, ненадежно и т. Д.?
Я слышал много слов «мы не можем этого сделать» от наших системных администраторов ... которые, наконец, когда я спросил более подробную информацию, они сказали: «ну, технически это возможно, но мы не делаем это здесь»
заранее спасибо,
Обновление: спасибо за ответы. (Все они были хороши: мне пришлось выбрать одну. Извините, если она не ваша). Как я и ожидал (отчасти): мои надежды, что вы можете просто прикрепить NTFS или XFS или любую другую «обычную» файловую систему к тому же самому фрагменту. «диск» оказался наивным. Кластерная файловая система - это билет. И модные файловые системы не входят в число главных приоритетов нашей команды хостинга).
"ну, технически это возможно, но у нас это не так"
Это очень похоже на то, что я регулярно говорю разработчикам;)
С точки зрения эксплуатации предприятия вы хотите, чтобы приложения максимально использовали стандартные повторяемые решения. Если ваше приложение не требует / не требует особого обращения, вы его не получите. Нестандартные решения требуют специализированных навыков, более дорогого или просто большего количества оборудования, и если это «современное» оборудование, то сбои также часто становятся катастрофическими.
Для многих приложений (высокодоступный) файловый ресурс по-прежнему является очень подходящим и широко применяемым решением.
Общие альтернативные решения высокой доступности для использования файлового ресурса:
Не храните файлы в файловых системах, а используйте высокодоступную базу данных и храните их как BLOB-объекты. Очень распространенный подход. Часто в любом случае вам уже нужна база данных, и это делает серверы приложений практически не имеющими состояния, решает множество проблем блокировки, репликации, высокой доступности, согласованности и доступа, перемещая их на уровень базы данных, где многие из этих проблем являются старыми новостями, хорошо понятыми и решено. Однако, как только вы достигнете (значительную часть) петабайтного диапазона, его обслуживание может оказаться дорогостоящим.
Надлежащая кластерная файловая система, которая обеспечивает одновременный блочный доступ для чтения и записи к вашему общему хранилищу через Fibre Channel или iSCSI. Корпоративные массивы хранения обычно довольно дорого но это очень хорошо масштабируется. Часто файловая система кластера требует (дорогостоящего) лицензирования для каждого узла программного обеспечения кластерной FS. Также довольно часто встречается в корпоративных средах для специализированных приложений.
Используйте распределенное хранилище объектов. Это решение с более открытым исходным кодом, с недорогим аппаратным обеспечением, обеспечивающим избыточность и масштабируемость программного обеспечения. Это распространенный «облачный» подход.
Если вы подключаете несколько серверов к общему блочному устройству (DASD / SAN), вам все равно нужно либо вручную управлять доступом к фрагментам диска (некоторые базы данных делают это на необработанных дисках, LVM также является вариантом с управляемым доступом к LV) или использовать кластерную файловую систему, которая будет управлять одновременным доступом.
Даже с блокировкой записи, управляемой для каждого файла, вы можете столкнуться с повреждением файловой системы в противном случае, если два хоста попытаются выполнить изменения метаданных FS одновременно на некластеризованной FS. Ничего современного в этом нет, кстати, SAN и одновременный блочный доступ существуют с 80-х (если не 70-х).
Все современные ОС имеют кластерные реализации FS, а изоляция блоков блоков также возможна, если вы готовы писать все самостоятельно, поэтому это очень зависит от того, что вы собираетесь использовать.
РЕДАКТИРОВАТЬ: Ваш «старый» подход к общему сетевому ресурсу все еще вполне осуществим, и файловый сервер позаботится о блокировках файлов, поэтому вам не нужны дополнительные механизмы блокировки. Если вам не нужна дополнительная производительность и вам нужно простое развертывание, это, вероятно, самый простой путь.
Теперь, если вы хотите говорить «современно», подумайте о хранилище объектов и масштабируемой архитектуре для вашего приложения.
Вам нужно не только общее оборудование, но и кластерная файловая система.
Обычные файловые системы не работают - два компьютера в конечном итоге перезаписывают изменения друг друга, и вы получите поврежденную файловую систему.
В кластерных файловых системах все компьютеры уведомляют друг друга об изменениях, которые они вносят, и обрабатывают файлы блокировки, когда это необходимо, чтобы они не наступали друг другу на пятки.
Некоторые из этих файловых систем зависят от приложения - например, у VMware есть VMFS, а у Hyper-V есть общие тома кластера - они отлично подходят для хранения виртуальных машин, но не предназначены для общего хранения файлов. Есть и другие, которые предназначены для хранения любых файлов. У каждого из них есть свои преимущества и недостатки, поэтому какой из них лучше всего зависит от того, что вы с ним делаете. Все они (насколько мне известно) специфичны для ОС - вы не сможете использовать файловую систему между Windows и Linux таким образом.
Это действительно необходимо для некоторых вещей, например, для переключения виртуальных машин с высокой доступностью. Для приложений, где работают SMB или NFS, они обычно предпочтительны - они могут быть немного медленнее, но гораздо меньше вещей, которые могут пойти не так, и их легче восстановить, если они действительно сломаются.