Розгортання файлів на декількох серверах


11

У нас є центральне сховище файлів у сервері say-1 at /srv/www. Тоді ми також маємо N кількість серверів. Ми хочемо, щоб сервер-1 мав змогу розгортати свої файли /srv/wwwна всіх серверах якомога швидше та ефективніше.

Чи є щось на зразок rsync, але замість того, щоб вказати одну ціль, вказавши кластер (N серверів) цілей?

Я думав, що gitможе спрацювати, але чи можемо ми вказати кілька віддалених пристроїв, щоб також натиснути?

Найкраще рішення, якщо припустити, що N серверів можуть досягти сотні.


2
Я припускаю, що мережева файлова система неможлива?
cjc

stackoverflow.com/questions/849308/… для отримання git хитрості до підключення до декількох дистанційних. Але не впевнений у сотнях.
cjc

Відповіді:


14

Ну, і Twitter, і Facebook почали використовувати bittorrent у своїх кластерах для розповсюдження нових оборотів коду. Роблячи це, вони в змозі перенести код на десятки тисяч серверів за дуже короткий проміжок часу порівняно із методами централізованого розгортання старої школи.

Це не схоже на те, що ви ще в такому масштабі, але немає ніякої шкоди в розробці системи розгортання, щоб вона не виявилася вузьким місцем незабаром.


1
Як вони використовують bittorrent?
Драгос

3
Дивіться статті, до яких я посилався.
EEAA

@EEAA twitter посилання розірвано
gprasant

@gprasant виправлено.
EEAA

7

Я не рекомендую git для ваг, з якими ви розмовляєте. Це може спрацювати, але я особисто бачу деякі дефіцити використання цієї моделі для отримання.

Є кілька речей, які визначають, як найкраще робити це:

  1. Наскільки велике репо потрібно поділити.
  2. Як швидко це потрібно для сходження.

Для досконалої конвергенції та максимальної швидкості вам доведеться працювати з мережевою файловою системою, наприклад NFSv4. Кластеризовані файлові системи, про які я знаю, не масштабуються до «кількох сотень» вузлів, тому це повинна бути мережева файлова система. Це представляє власні проблеми, але це означає, що ви досягнете конвергенції з моменту оновлення файлів на голові NFS.

Для швидкої конвергенції можна скористатися деякою хитрістю rsync. Якщо демон rsync в кінцевому підсумку пов'язаний з процесором, ви, безумовно, можете поставити пару-три сервери rsync за балансиром навантаження, як haproxy. У поєднанні з завданнями cron, щоб отримати дані (або якийсь інший метод запуску оновлень коду), ви можете досить швидко досягти конвергенції.

Для обох вищезазначених, ймовірно, буде гарною ідеєю розмістити центральний сховище на 10GbE-посиланнях для максимальної пропускної здатності.

Замінник - це push-rsync, де він запускається з центрального репо, щоб надсилати оновлення на ваші сервери. Він не збігатиметься так швидко, як будь-яке з перерахованих вище, але буде більш привітним до вашої внутрішньої пропускної здатності. Для кращої швидкості використовуйте декілька хостів, які натискають на розділені діапазони.



-1

[афілійований] Використовуючи Kwatee ( http://www.kwatee.net ), ви можете розгортати на будь-якій кількості серверів, наскільки вам потрібно. Розгортання є поступовим (передаються лише модифіковані файли) і їх можна паралелізувати так швидко. Ви також можете налаштувати Kwatee таким чином, щоб він був в курсі навантаження, щоб сервери були вилучені з LB під час оновлень, а потім повторно вставлені. Існує графічний інтерфейс для налаштування параметрів розгортання, а потім розгортання можна запускати вручну через GUI або автоматизувати за допомогою команд python.


Ви хочете пояснити протизаконний голос?
мак

1
Приєднання до сайту просто для сутенерства до власного продукту часто тут збирає обертів.
ceejayoz

Незважаючи на те, стільки за чесні та прозорі відповіді
mac
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.