1. Вступ Існує безліч факторів, які необхідно враховувати при виборі серверного оточення (environment),...
2. 2. Виділений сервер баз даних
3. 3. Балансувальник навантаження (зворотний проксі)
4. 4. HTTP Accelerator (кешуючий зворотний проксі)
5. 5. Реплікація бази даних по схемі провідний-ведений (Master-Slave)
6. Приклад: комбінування концепцій
7. висновок

Вступ

Існує безліч факторів, які необхідно враховувати при виборі серверного оточення (environment), такі як продуктивність, масштабованість, доступність, надійність, вартість і простота управління.

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

1. Всі на одному сервері

Оточення знаходиться на одному сервері. Для типового веб-додатки вона буде включати в себе веб-сервер, сервер додатків і сервер баз даних. Окремим випадком реалізації цього набору є стек LAMP, назва якого є скорочення від Linux, Apache, MySQL та PHP, на одному сервері.

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

плюси:

мінуси:

• Додаток і база даних використовують одні і ті ж ресурси сервера (CPU, пам'ять, I / O і т.д.), що, крім потенційно низьку продуктивність, ускладнює визначення джерела (додаток або база даних) цієї самої низької продуктивності.
• Скрутно здійснювати горизонтальне масштабування.

Додаткові керівництва:

2. Виділений сервер баз даних

Система управління базами даних (СКБД) може бути відокремлена від решти оточення, щоб виключити конкуренцію за ресурси сервера між додатком і базою даних і посилити безпеку, прибравши базу даних з DMZ, загальнодоступного інтернету.

Приклад використання: Добре підходить для швидкого розгортання програми, але при цьому усуває проблему конкуренції додатки і бази даних за одні системні ресурси.

плюси:

• Додаток і база даних не конкурують за одні й ті ж ресурси сервера (CPU, пам'ять, I / O і т.д.).
• Ви можете вертикально масштабувати кожен компонент (додаток і базу даних) незалежно один від одного, додаючи додаткові ресурси до потрібного сервера.
• При певних налаштуваннях це може підвищити безпеку, прибравши базу даних з DMZ.

мінуси:

• Процес установки трохи складніший, ніж в разі використання одного сервера.
• Можуть виникати проблеми з продуктивністю, якщо мережеве з'єднання між двома серверами має великий час відгуку (наприклад, сервери географічно віддалені один від одного) або пропускна здатність недостатня для переданих даних.

Додаткові керівництва:

3. Балансувальник навантаження (зворотний проксі)

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

Приклади програмного забезпечення, що підтримує зворотний проксі: HAProxy, Nginx, і Varnish.

Приклад використання: Корисний для оточення, яке вимагає масштабування шляхом додавання додаткових серверів, так само відоме як горизонтальне масштабування.

плюси:

• Уможливлює горизонтальне масштабування, тобто ресурси оточення можуть бути збільшені шляхом додавання в нього нових серверів.
• Може захистити від DDOS-атак шляхом обмеження клієнтських з'єднання до прийнятного кількості і частоти.

мінуси:

• Балансувальник навантаження може стати вузьким місцем в продуктивності, якщо він відчуває нестачу ресурсів або погано налаштований.
• Може створити додаткові складнощі, що вимагають додаткових зусиль від адміністратора, наприклад, робота з додатками, які вимагають так званих "липких сесій" (sticky session).

Додаткові керівництва:

4. HTTP Accelerator (кешуючий зворотний проксі)

HTTP accelerator, або кешуючий HTTP-запити зворотний проксі-сервер, може бути використаний для зменшення часу, необхідного для надання контенту користувачеві, за допомогою різних методів. Основою метод, який використовується з HTTP accelerator, це кешування відповідей від веб-сервера або сервера додатків в пам'яті, при цьому наступні запити на той же самий контент можуть бути оброблені швидко і меншою кількістю зайвих взаємодій з веб-сервером або сервером додатків.

Приклади програмного забезпечення, що підтримує HTTP acceleration: Varnish, Squid, Nginx.

Приклад використання: Корисний для динамічних веб-додатків з важким контентом або з великою кількістю файлів, до яких можливий одночасний доступ.

плюси:

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

мінуси:

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

Додаткові керівництва:

5. Реплікація бази даних по схемі провідний-ведений (Master-Slave)

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

Приклад використання: Дає гарне збільшення продуктивності додатка в частині читання з бази даних.

Ось приклад реплікації бази даних по схемі провідний-ведений з одним відомим вузлом:

плюси:

• Покращує продуктивність читання з бази даних шляхом розподілу запитів на читання між відомими вузлами.
• Може поліпшити продуктивність записи шляхом використання провідного вузла виключно для запису (таким чином він не витрачає час на обслуговування запитів на читання)

мінуси:

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

Додаткові керівництва:

Приклад: комбінування концепцій

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

Ось приблизна діаграма того, як може виглядати серверне оточення:

Давайте припустимо, що балансувальник навантаження налаштований на розпізнавання статичних запитів (таких як зображення, CSS, JavaScript і т.д.) і відправляє ці запити до серверів кешування, а всі інші запити - до серверів додатків.

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

1. Користувач запитує динамічний контент з http://example.com/ (Балансувальник навантаження).
2. Балансувальник навантаження надсилає запит на сервер додатки (app-backend).
3. Сервер додатка (app-backend) читає з бази і повертає запитуваний контент назад балансувальник навантаження.
4. Балансувальник навантаження повертає запитуваний контент користувачеві.

Якщо користувач запитує статичний контент:

1. Балансувальник навантаження перевіряє кеш (cache-backend) на предмет того, закешовану чи запитуваний контент.
2. Якщо закешовану, то запитуваний контент повертається балансірощіку навантаження, переходимо в кроці 7. Якщо не закешовану, то сервер кешування перенаправить запит на сервер додатки через балансувальник навантаження.
3. Балансувальник навантаження перенаправить запит на сервер додатки.
4. Сервер додатка (app-backend) читає з бази і повертає запитуваний контент назад балансувальник навантаження.
5. Балансувальник навантаження перенаправляє відповідь до сервера кешування (cache-backend).
6. Сервер кешування кешируєт отриманий контент і повертає його балансувальник навантаження.
7. Балансувальник навантаження повертає запитуваний контент користувачеві.

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

висновок

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

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