В настоящее время мы используем производную от NoSQL под названием Splunk для получения наших данных. Программное обеспечение поддерживает так называемое «объединение поисковых заголовков», при котором механизм распределения заданий размещается на нескольких серверах, которые совместно используют общую точку хранения. Первоначально мы намеревались использовать кластерную файловую систему, такую как GFS2, из-за низкой задержки, стабильности и простоты настройки. Мы установили GFS2, и он работает без проблем.
Однако при попытке запустить программное обеспечение оно пытается создать файлы блокировки и множество других вещей, которые их служба поддержки не может полностью объяснить. Окончательный ответ от них заключался в том, что они поддерживают только NFS.
Наша команда сетевого администрирования серьезно относится к NFS (отсутствие стабильности, проблемы с блокировкой файлов и т. Д.).
Итак, я думал о возможности настроить NFS на каждом сервере в кластере, чтобы он действовал как клин между файловой системой GFS2 и программным обеспечением. В основном настройте каждый сервер для экспорта точки монтирования файловой системы GFS2 через NFS, а затем сообщите каждому серверу о необходимости подключения к этому общему ресурсу NFS. Таким образом, мы не вводим какие-либо точки отказа в случае отказа выделенного сервера NFS, но поставщик получает свой «необходимый» общий ресурс NFS.
Я просто обдумываю способы, так что, пожалуйста, разорвите это на части :)
В способ блокировки GFS2 работает, вы можете увидеть серьезные проблемы с производительностью, если укажете каждый узел на другой сервер NFS:
Если другой узел запрашивает глок, который не может быть предоставлен немедленно, то DLM отправляет сообщение узлу или узлам, которые в настоящее время содержат глоки, блокирующие новый запрос, чтобы попросить их снять свои блокировки. Удаление глоков может быть (по стандартам большинства операций с файловой системой) долгим процессом. Для удаления общего глока необходимо только сделать кеш недействительным, что относительно быстро и пропорционально количеству кэшированных данных.
Удаление эксклюзивного глока требует сброса журнала и обратной записи любых измененных данных на диск с последующим аннулированием в соответствии с общим глоком.
[...]
Благодаря способу реализации кэширования GFS2 наилучшая производительность достигается при любом из следующих условий:
- Inode используется только для чтения на всех узлах.
- Inode записывается или изменяется только с одного узла.
Дополнительно, сопроводительные документы как у Red Hat указывают, что блокировки POSIX на общих ресурсах NFS будут вызывать проблемы, поэтому только конфигурации Active / Passive кластеризации, в которых NFS экспортируется из один активный узел в любой момент времени и доступ к файлам в файловой системе GFS2 не осуществляется, за исключением того, что поддерживается службой NFS. Очевидно, это должно позаботиться о любых непредвиденных взаимодействиях блокировки между NFS и GFS2, но, вероятно, это не то, что вы хотели видеть.