Завантажити балансування Apache на бюджет?

Я намагаюся обернутись концепцією збалансування навантаження, щоб забезпечити доступність та надмірність, щоб підтримувати користувачів щасливими, коли справи йдуть не так, а не балансування навантаження заради пропонування швидкістю для мільйонів користувачів.

Ми готові до бюджету і намагаємось дотримуватися того, де є багато знань, тому запуск Apache на Ubuntu VPS здається стратегією, поки якийсь відомий пошуковий механізм не придбає нас ( включено іронічну суботу ).

Принаймні для мене, це повна джунглі з різних рішень. Власні mod_proxy & HAproxy - це два, які ми знайшли шляхом швидкого пошуку в Google, але, маючи нульовий досвід збалансування навантаження, я не маю уявлення про те, що було б підходящим для нашої ситуації, або що ми б доглядали, вибираючи рішення для вирішення нашої проблеми щодо доступності.

Який найкращий варіант для нас? Що ми повинні зробити, щоб забезпечити високу доступність, залишаючись у наших бюджетах?

Я використовую рішення, яке легко реалізується за допомогою VPS, таке:

• DNS кругообіг (sp?) Для 6 різних дійсних IP-адрес.
• У мене є 3 балансири навантаження з однаковою конфігурацією та використовують коросинхронізацію / кардіостимулятор для розподілу 6-ти ip адрес рівномірно (тому кожна машина отримує 2 адреси).
• Кожен з балансирів навантаження має конфігурацію лаку nginx + . Nginx займається отриманням з'єднань, перезаписом і статичним обслуговуванням, і передачею його назад до Varnish, який робить балансування навантаження та кешування.

На мою необ’єктивну думку ця арка має такі переваги:

1. corosync / пейсмейкер буде перерозподіляти ip-адреси у випадку відмови одного з LB.
2. nginx може використовуватися для обслуговування SSL, певних типів файлів безпосередньо з файлової системи або NFS без використання кешу (великі відео, аудіо чи великі файли).
3. Лак - це дуже хороший балансир навантаження, що підтримує вагу, перевіряє стан здоров'я та виконує відмінну роботу як зворотний проксі.
4. У випадку, коли для обробки трафіку потрібно більше LB, просто додайте більше машин до кластеру, і IP-адреси будуть відновлені між усіма машинами. Ви навіть можете це зробити автоматично (додавання та видалення балансирів навантаження). Ось чому я використовую 6 ips для 3-х машин, щоб дати трохи місця для зростання.

У вашому випадку, фізично відокремлені VPS - це хороша ідея, але ускладнює обмін ip складніше. Мета полягає у створенні стійкої до відмов резервної системи та деяких конфігурацій для врівноваження навантаження / кінцевого навантаження, які змішують її, додаючи єдину точку відмови (наприклад, один балансир навантаження для отримання всього трафіку).

Я також знаю, що ви запитували про apache, але в ті дні ми маємо конкретні інструменти, які краще підходять для роботи (наприклад, nginx та лак). Залиште apache запускати програми на бекенді та обслуговувати його за допомогою інших інструментів (не те, що apache не може зробити гарне балансування навантаження або зворотне проксі, це лише питання про завантаження різних частин роботи на більше служб, щоб кожна частина могла робити добре це частка).

HAproxy - хороше рішення. Конфігурація досить пряма вперед.

Вам знадобиться інший екземпляр VPS, щоб сісти перед принаймні двома іншими VPS. Тому для балансування / відмови навантаження потрібно мінімум 3 VPS

Кілька речей, про які варто також подумати:

1. Закінчення SSL. Якщо ви використовуєте HTTPS: //, це з'єднання має припинятися на балансирі навантаження, за балансиром навантаження він повинен передавати весь трафік через незашифроване з'єднання.

2. Зберігання файлів. Якщо користувач завантажує зображення, куди воно йде? Це просто сидить на одній машині? Вам потрібно якось миттєво ділитися файлами між машинами - ви можете використовувати сервіс Amazon S3 для зберігання всіх своїх статичних файлів, або у вас може бути інша VPS, яка буде виконувати функцію файлового сервера, але я б рекомендував S3, оскільки його надмірно та шалено дешево.

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

4. db - у вас є окремий сервер db? якщо у вас є лише одна машина зараз, як ви переконаєтесь, що ваша нова машина матиме доступ до db-сервера - і якщо це окремий сервер db VPS, наскільки це зайве. Це не обов'язково має сенс мати передні веб-сайти з високою доступністю та єдину точку відмови з одним db-сервером, тепер також слід врахувати реплікацію db та просування в ведених.

Тому я був у вашому взутті, ось проблема з веб-сайтом, який робить кілька сотень звернень на день до справжньої операції. Це стає складним швидко. Сподіваюся, що дав вам трохи їжі для роздумів :)

Моє голосування за Віртуальний сервер Linux як балансир навантаження. Це робить директора LVS єдиною точкою відмови, а також вузьким місцем, але

1. На моєму досвіді вузьке місце не є проблемою; крок перенаправлення LVS - це рівень 3, і надзвичайно (обчислювально) дешево.
2. Єдину точку відмови слід вирішувати, маючи другого директора, з двома, якими керує Linux HA .

Витрати можна зменшити, якщо перший директор знаходиться на тій же машині, що і перший вузол LVS, а другий директор на тій же машині, що і другий вузол LVS. Треті та наступні вузли - це чисті вузли, без наслідків LVS або HA.

Це також дозволяє вам запускати будь-яке програмне забезпечення веб-сервера, яке вам подобається, оскільки перенаправлення відбувається нижче рівня додатка.

Як щодо цього ланцюжка?

круглий robin dns> haproxy на обох машинах> nginx для відокремлення статичних файлів> apache

Можливо, також використовуйте ucarp або серцебиття, щоб гарантувати, що гапрокси завжди відповідає. Stunnel буде сидіти перед haproxy, якщо вам також потрібен SSL

Ви можете розглянути можливість використання програмного забезпечення для кластеризації. Кластерний пакет RedHat (або CentOS) або ClusterWare Oracle . Вони можуть бути використані для налаштування активних пасивних кластерів, а також можуть використовуватися для перезавантаження служб та відмовлення між вузлами, коли виникають серйозні проблеми. Це по суті те, що ви шукаєте.

Усі ці кластерні рішення включені у відповідні ліцензії на ОС, тому ви, мабуть, круті за вартістю. Вони вимагають певного способу спільного зберігання - або кріплення NFS, або фізичного диска, до якого обидва вузли мають доступ з кластерною файловою системою. Прикладом останнього можуть бути диски SAN з дозволеним декількома хостами, відформатовані з OCFS2 або GFS . Я вважаю, що ви можете використовувати для цього спільні диски VMWare .

Програмне забезпечення кластера використовується для визначення "служб", які працюють на вузлах весь час або лише тоді, коли цей вузол "активний". Вузли спілкуються через серцебиття, а також контролюють ці служби. Вони можуть перезапустити їх, якщо помічають збої, і перезавантажити, якщо їх не вдасться виправити.

Ви в основному налаштуєте одну спільну IP-адресу, на яку буде спрямований трафік. Тоді апачі та будь-які інші необхідні сервіси можуть бути визначені також і працювати лише на активному сервері. Спільний диск буде використовуватися для всього вашого веб-вмісту, будь-яких завантажених файлів та ваших каталогів конфігурації apache. (з httpd.conf тощо)

На мій досвід, це працює неймовірно добре.

• Немає необхідності в кругообігу DNS або будь-якому іншому балансировочному навантажувачі з одною точкою відмови - все потрапляє в один IP / FQDN.
• Завантажені користувачем файли переходять у спільне сховище, і, таким чином, не хвилюється, чи перестає працювати машина.
• Розробники завантажують вміст у той самий IP / FQDN без нульової додаткової підготовки, і це завжди актуально, якщо він не завершиться.
• Адміністратор може взяти автономну машину, виправити хек з неї, перезавантажити тощо. Потім провалить активний вузол. Оновлення потребує мінімального простою.
• Цей застарілий вузол може залишатися без виправлення деякий час, що робить відмову не менш легким процесом. (Швидше, ніж знімки VMWare)
• Зміни в конфігурації Apache є спільними, так що нічого дивного не відбувається під час відмови, оскільки адміністратор забув внести зміни в офлайн-поле.

- Крістофер Карел

Оптимальне балансування навантаження може бути дуже дорогим і складним. Базове балансування навантаження повинно просто забезпечити, щоб кожен сервер обслуговував приблизно однакову кількість звернень у будь-який час.

Найпростіший метод збалансування навантаження - це надання декількох записів A у DNS. За замовчуванням IP-адреса буде налаштована методом круглої роботи. Це призведе до того, що користувачі відносно рівномірно розподіляться між серверами. Це добре працює для сайтів без громадянства. Трохи складніший метод потрібен, коли у вас є великий сайт.

Для обробки важливих вимог можна використовувати переадресації. Дайте кожному веб-серверу альтернативну адресу, таку як www1, www2, www3 тощо. Перенаправляйте початкове з'єднання www на альтернативну адресу хоста. У вас можуть виникнути проблеми із закладками таким чином, але вони повинні бути рівномірно розподілені по серверам.

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

Вихід з відмовою може бути оброблений, налаштувавши сервер на отримання IP-адреси невдалого сервера. Це дозволить мінімізувати час простою, якщо сервер не працює. Без кластерного програмного забезпечення, якщо сервер вийде з ладу, потужні сеанси будуть втрачені.

Без відмови користувачі зазнають затримки, поки їх браузер не перейде на наступну IP-адресу.

Використання відпочинкових сервісів, а не державних сеансів повинно усунути проблеми кластеризації на передній частині. Проблеми кластеризації на стороні зберігання зберігаються.

Навіть з балансирами навантаження перед серверами, швидше за все, перед вами буде DNS з круглим доступом. Це забезпечить використання всіх ваших балансирів навантаження. Вони додадуть вашому дизайну ще один шар, з додатковою складністю та ще однією точкою відмови. Однак вони можуть надати деякі функції безпеки.

Найкраще рішення залежатиме від відповідних вимог.

Реалізація серверів зображень для обслуговування вмісту, такого як зображення, файли CSS та інший статичний вміст, може полегшити навантаження на сервери додатків.

Я зазвичай використовую пару однакових машин OpenBSD:

• Використовуйте RelayD для балансування навантаження, моніторингу веб-сервера та обробки несправного веб-сервера
• Використовуйте CARP для високої доступності самих балансирів навантаження.

OpenBSD легкий, стабільний і досить безпечний - ідеально підходить для мережевих послуг.

• http://www.openbsd.org - Головний сайт
• http://www.openbsd.org/faq/pf/carp.html - документація на королів
• https://calomel.org/relayd.html - Пристойний набір інформації про те, як реалізувати RelayD

Для початку рекомендую налаштування layer3. Це дозволяє уникнути ускладнень з налаштуванням брандмауера (PF). Ось приклад файлу /etc/relayd.conf, який показує налаштування простого реле-балансира навантаження з моніторингом задніх веб-серверів:

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

Чи подарували вам ec2 з хмарними хвилями чи, можливо, еластичним пюре або просто простим старим AWS, який автоматично розгортає думку. Я використовую це, і це масштабує досить добре, і еластичність може змінюватись / зменшувати без будь-якого втручання людини.

Зважаючи на те, що ви кажете, що у вас немає нульового досвіду з балансуванням навантаження, я б запропонував ці варіанти, оскільки для того, щоб піднятися та працювати, вони вимагають мінімальної «смаження» мозку.

Можливо, краще використовувати свій час.