Комментарии 10
Active-active с NFS можно сделать?
в описанной реализации это невозможно. Для Active-active нужны кластерные ФС. Тут можно только сделать размазывание NFS ресурсов по узлам
У drbd есть diskless устройство, можно просто его монтировать с кластерной фс.
Но это накладывает ограничения на необходимость настройки модуля ядра drbd на клиенте, чего в случае с nfs делать не надо и более универсально получается.
Если ниже уровнем находится Варя, зачем эти игры с softdog?
https://vm-guru.com/news/vmware-vsphere-7-vm-watchdog-timer
И если у Вас уже есть Shared Disk, то к чему эти игры с pacemaker?
Чем automount(8) daemon не подходит?
https://www.redhat.com/sysadmin/mount-nfs-filesystems-autofs
vWDT это просто еще одна реализация watchdog. Не знал о его существовании. Но, наверное, не стал бы использовать. Хотелось получить универсальное решение. В описанном решении softdog нужен не только как классический watchdog, через него Pacemaker проводит обработку отказа в различных сценариях.
Судя по статье, он поддерживается с vSphere 8.0, у нас версия была младше. Может еще какие-либо ограничения есть. Если когда-нибудь доведется, попробую, спасибо.
Использовал automount на стороне клиента. Как его прикрутить для общего диска и не допустить множественного доступа с нескольких узлов, не понятно.
Эрм,
1) watchdog доступен просто с 7-й
2) статья о которой Вы не совсем связана с watchdog механизмом о котором я говорил, там уже про правильную интеграцию RHEL кластеров
3) automount можно прикрутить на два ip адреса и таймер, на то, что делать при недоступности первого пути
Так описанное решение в публикации и есть реализация RHEL High Availability Cluster. Если бы делали решение под конкретного вендора, то полностью следовали бы его рекомендациям (по правильной реализации High Availability Cluster). В своем предыдущем комментарии указал, что просто для этого нужен vSphere 8.0 т.к. именно Pacemaker будет взаимодействовать с vWDT. Пожалуйста, укажите где я не прав.
Извините, все равно не понимаю, как automount можно безопасно использовать, имея несколько серверов приложений, NFS и общий диск.
Комментарий понял так: на серверах приложений прописываем в automount несколько NFS серверов. При недоступности одного NFS сервера, приложения подключаются к другому.
Представьте ситуацию, активный NFS сервер стал недоступен, все клиенты подключились к следующему. Недоступный NFS сервер возвращается в работу, возможны следующие проблемы:
1. Нет гарантий, что все клиенты смогут синхронно переподключиться к возвращенному в работу NFS серверу
2. Клиенты продолжат работать с текущим NFS сервером. Но тут уже серверу приложений надо перезагрузиться. Насколько понимаю, он подключится к возвращенному в работу NFS серверу
Оба эти сценария могут привести к множественному доступу на запись к общему диску, что привести к утрате данных.
Поэтому используется Pacemaker и входная точка, которой он управляет, для гарантии согласованного доступа к диску.
Я сейчас не про взаимодействие pacemaker и vSphere. А про банальный Watchdog, который Варя эмулирует как железный для ОС. И ему не важно хоть все ядра повисли намертво или вся ОС ушла в kernel panic и заняла все ядра.
У Вас же по условиям статичный набор клиентов?
"Сервис — java-приложение, запущенное на нескольких ВМ."
Если мы волнуемся, что сервер приложений будет перезапущен - keepalived идеально поможет
S3 не подходил из-за высокой стоимости поддержки и нецелесообразности для планируемых нагрузок.
А можно пояснить чем сложно поддерживать s3 minio? Он запускается за 5 мин в кластерном варианте. Уже в продакшене 2 года. У вас всего 10 файлов в минуту.
Отвечая на вопрос, напомню, что он основан на моем субъективном мнении и опыте. Учитывал контрактные обязательства перед заказчиком, опыт работы с ним, текущую инфраструктуру. Возможно, для Вас все сказанное будет неактуально. Основными критериями выбора в пользу POSIX ФС стали:
1. Более низкая стоимость разработки сервиса. Возможно, программисты скажут, что нет разницы или что S3 даже проще.
2. Административный ресурс. Сложнее найти на рынке специалистов, имеющих опыт развёртывания и эксплуатации Minio или Ceph, чем с pacemaker. Не говоря уже о том, чтобы обучить их этому. S3 более сложен для понимания, чем pacemaker с NFS.
3. Мониторинг. Текущая система мониторинга умеет работать с pacemaker и NFS. Внедрение Minio потребовало бы обновления системы мониторинга или реализации мониторинга через дополнительные скрипты.
4. Резервное копирование и восстановление. С S3 сложнее восстанавливать, особенно весь кластер при его утрате. Система резервного копирования заказчика не умеет создавать резервные копии с S3.
5. Администрирование. Восстановление узла, расширение доступного пространства – операции проще в предложенной реализации. У Minio появляются дополнительные сложности в виде ребалансировки (из того, что сразу пришло в голову).
6. Аппаратные ресурсы. В текущей инфраструктуре диски подаются с FC фабрики. Minio реализует собственную отказоустойчивость с использованием локальных дисков. FC диски дорого использовать для Minio.
Наверное, это основное, что вспомнил. Под требования проекта весомых плюсов от реализации S3 совместимого хранилища не увидел.
Отдельно скажу, что S3, и Minio в частности, используем на других проектах, где видим выигрыш от его реализации.
Ещё один рецепт отказоустойчивого файлового сервера средствами PaceMaker