Избегайте SPOFS с GlusterFS и Windows

У нас есть кластер GlusterFS, который мы используем для нашей функции обработки. Мы хотим интегрировать в него Windows, но у нас возникли проблемы с выяснением того, как избежать единой точки отказа, которая представляет собой сервер Samba, обслуживающий том GlusterFS.

Наш файловый поток работает так:

1. Файлы читаются узлом обработки Linux.
2. Файлы обработаны.
3. Результаты (могут быть маленькими или довольно большими) записываются обратно на том GlusterFS по мере их выполнения.
   • Вместо этого результаты могут быть записаны в базу данных или могут включать несколько файлов разных размеров.
4. Узел обработки выбирает другое задание из очереди и GOTO 1.

Gluster хорош тем, что обеспечивает распределенный объем, а также мгновенную репликацию. Устойчивость к бедствиям - это хорошо! Нам это нравится.

Однако, поскольку Windows не имеет собственного клиента GlusterFS, нам нужен какой-то способ, чтобы наши узлы обработки на базе Windows могли взаимодействовать с хранилищем файлов таким же устойчивым образом. В Состояния документации GlusterFS что способ предоставить доступ Windows - это установить сервер Samba поверх смонтированного тома GlusterFS. Это приведет к такому потоку файлов:

Для меня это похоже на единственную точку отказа.

Один из вариантов - кластерная Samba, но похоже, что это связано с нестабильным кодом прямо сейчас и, следовательно, не работает.

Поэтому ищу другой способ.

Некоторые ключевые подробности о типах данных, которые мы разбрасываем:

• Исходные размеры файлов могут быть от нескольких КБ до десятков ГБ.
• Размер обрабатываемых файлов может быть от нескольких КБ до одного или двух ГБ.
• Определенные процессы, такие как копание в архивном файле, таком как .zip или .tar, могут вызвать МНОГО дальнейших записей, поскольку содержащиеся файлы импортируются в хранилище файлов.
• Количество файлов может достигать десятков миллионов.

Эта рабочая нагрузка не работает с настройкой Hadoop «статический размер рабочей единицы». Точно так же мы оценивали хранилища объектов в стиле S3, но обнаружили, что они отсутствуют.

Наше приложение специально написано на Ruby, и у нас есть среда Cygwin на узлах Windows. Это может нам помочь.

Один из вариантов, который я рассматриваю, - это простая HTTP-служба на кластере серверов, на которых установлен том GlusterFS. Поскольку все, что мы делаем с Gluster, - это, по сути, операции GET / PUT, это кажется легко переносимым на метод передачи файлов на основе HTTP. Поместите их за парой балансировщиков нагрузки, и узлы Windows смогут выполнять HTTP PUT в свое маленькое голубое сердце.

Я не знаю как будет поддерживаться согласованность GlusterFS. Уровень HTTP-прокси обеспечивает достаточную задержку между тем, когда узел обработки сообщает, что это выполнено с записью, и когда он действительно виден на томе GlusterFS, что меня беспокоит, что на более поздних этапах обработки попытки забрать файл не будут Найди это. Я почти уверен, что используя direct-io-mode=enable mount-option поможет, но я не уверен, достаточно ли этого. Что еще мне нужно делать для улучшения согласованности?

Или я должен использовать совсем другой метод?

Как указал Том ниже, еще один вариант - NFS. Итак, я провел тест. Поскольку вышеупомянутые файлы имеют имена, предоставленные клиентом, которые нам необходимо сохранить, и могут быть на любом языке, нам действительно необходимо сохранить имена файлов. Итак, я создал каталог с этими файлами:

Когда я монтирую его из системы Server 2008 R2 с установленным клиентом NFS, я получаю следующий список каталогов:

Ясно, что Unicode не сохраняется. Так что NFS мне не подходит.