У нас є кластер GlusterFS, який ми використовуємо для своєї функції обробки. Ми хочемо інтегрувати в нього Windows, але у нас виникають певні проблеми, як з'ясувати, як уникнути єдиного пункту відмови - це сервер Samba, який обслуговує об'єм GlusterFS.
Наш потік файлів працює так:
- Файли зчитуються вузлом обробки Linux.
- Файли обробляються.
- Результати (можуть бути невеликими, можуть бути досить великими) списуються в об'єм GlusterFS, коли вони зроблені.
- Результати замість цього можуть бути записані в базу даних або можуть містити кілька файлів різного розміру.
- Вузол обробки знімає чергове завдання з черги та GOTO 1.
Gluster чудовий тим, що забезпечує розподілений обсяг, а також миттєву реплікацію. Стійкість до катастроф приємна! Нам це подобається.
Однак, оскільки у Windows немає рідного клієнта GlusterFS, нам потрібен спосіб взаємодії наших вузлів обробки Windows з файловим сховищем аналогічно еластичним способом. Документація GlusterFS зазначає, що спосіб надання доступу до Windows - це налаштування сервера Samba поверх встановленого тома GlusterFS. Це призведе до потоку файлів таким чином:
Для мене це схоже на те, що я не вдавався.
Один із варіантів - це кластеризація Samba , але, схоже, вона базується на нестабільному коді зараз і, таким чином, не працює.
Тому я шукаю інший метод.
Деякі основні деталі про типи даних, які ми передаємо:
- Оригінальні розміри файлів можуть бути від кількох КБ до десятків ГБ.
- Розміри файлів, що обробляються, можуть бути від кількох КБ до ГБ або двох.
- Деякі процеси, такі як копання в архівному файлі, наприклад.
- Підрахунок файлів може потрапити в десятки мільйонів.
Це навантаження не працює при налаштуванні Hadoop на "статичний розмір роботи". Так само ми оцінювали магазини об’єктів у стилі S3, але виявляли їх відсутність.
Наш додаток написано на рубіні, і у нас є середовище 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стабільним та готовим до використання для виробництва, і перше речення у посиланні, яке ви надали, робить друге недійсним, тому що якщо воно ніколи не було оновлено. Я планував це встановити, але перед тим, як обійтись до цього, я переключив роботу на майже вільне середовище.