У нас есть кластер GlusterFS, который мы используем для нашей функции обработки. Мы хотим интегрировать в него Windows, но у нас возникли проблемы с поиском способов избежать единой точки отказа - сервера Samba, обслуживающего том GlusterFS.
Наш файловый поток работает так:
- Файлы читаются узлом обработки Linux.
- Файлы обрабатываются.
- Результаты (могут быть небольшими, могут быть довольно большими) записываются обратно в том GlusterFS по мере их выполнения.
- Вместо этого результаты могут быть записаны в базу данных или могут содержать несколько файлов различных размеров.
- Узел обработки забирает другое задание из очереди и 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 поможет, но я не уверен, что этого достаточно . Что еще я должен сделать, чтобы улучшить согласованность?
Или я должен искать другой метод полностью?
Как отметил Том ниже, NFS - это еще один вариант. Итак, я провел тест. Так как вышеупомянутые файлы имеют предоставленные клиентом имена, которые нам нужно сохранить, и могут быть на любом языке, нам нужно сохранить имена файлов. Поэтому я создал каталог с этими файлами:
Когда я монтирую его из системы Server 2008 R2 с установленным клиентом NFS, я получаю список каталогов, например:
Ясно, что Unicode не сохраняется. Так что NFS не будет работать на меня.
ctdbстабильной и готовой к использованию, и первое предложение в приведенной вами ссылке делает второе недействительным, потому что если оно никогда не обновлялось. Я планировал создать это, но прежде чем я смог обойти это, я переключился на работу практически без окон.