SlideShare a Scribd company logo
1 of 13
ЯК НЕ ВТРАТИТИ МІЛЬЙОН:
ПОБУДОВА ВІДМОВОСТІЙКОГО
КЛАСТЕРА
ВИСОКОНАВАНТАЖЕНИХ ВЕБ-
СЕРВЕРІВ
ХМАРИ – ЦЕ
Олексій Кириченко, GigaCloud
Задача
Особливість проекту
• Створення відмовостійкого рішення для
порталу великого веб-магазину – з гарантією
доступності сервісу 24/7.
• Перехід на нову архітектуру без зупинки
сервісу.
Вертикальна ІТ-архітектура з високою
вірогідністю недоступності системи при
апаратних збоях
1. Створення балансування на рівні мережі.
2. Резервування і балансування web-серверів.
3. Резервування і балансування бази даних.
Етапи переходу на нову архітектуру
Створення балансування на рівні
мережі
• Використовуємо сервіс HAProxy на серверах
балансування, що знаходяться у різних дата-центрах
• Зв'язок між серверами балансування й іншими сервісами
забезпечується розтягнутим L2 доменом
Ресурси
2 Гб дискового простору
4 ядра процессора
з розрахунку на кожен сервер
256 Мб оперативної пам'яті
Резервування і балансування web-серверів
• Використовуємо сервер синхронізації lsyncd у режимі
source-destination
• Перезапускаємо кожен web-сервер із кластера
• Проводимо резервування на рівні web-сервера, при цьому
навантаження розподіляється між серверами
Ресурси
х2 дисковий простір (додатково)
½ процесорної потужності з завантаженням 60-70%
з розрахунку на кожен сервер
½ оперативної пам'яті
Вхідна інформація про базу даних
Співвідношення операцій
запис/читання
20/100
Загальний рівень
операцій в секунду 75
Резервування і балансування бази даних
Її переваги:
• безперервність доступу
(відсутня необхідність ручного або автоматичного призначення нового
основного сервера, а отже відсутні і втрати часу)
• гарантія 100% збереження даних
Вирішили використовувати архітектуру master + master
Дозволяє обробити понад 1000
запитів запису+поновлення в
секунду
Резервування і балансування бази даних
VS
Переваги сервісу
• підвищена стійкість
• краще збереження цілісності даних
після краху
• відмінна сумісність з MyISAM
НАШ ВЫБОР
Готові рішення для архітектури master + master
Балансування трафіку на сервери бази даних
– універсальний балансувальник трафіку + додаткові налаштування для перевірки стану DB
Встановлюємо на веб-сервери, а не на окремі віртуальні машини.
• перевірка доступності кожної ноди за допомогою тестових
запитів
• виключення помилкової ноди до моменту відновлення
коректної роботи
• при розсинхронуванні вмикається режим роботи з однією
нодою з максимальною версією реплікації
• рівномірний розподіл запитів між усіма нодами
• створення бекапів незалежно на кожній ноді
Можливості
Фізична схема підключення віртуальних машин
Логічна схема підключення віртуальних
машин
Загальна схема кластера
Дякую за увагу!

More Related Content

Similar to Алексей Кириченко. "Как не потерять миллион". IT-пятница, сентябрь 2018

"Key considerations in implementing a distributed message-sending system usin...
"Key considerations in implementing a distributed message-sending system usin..."Key considerations in implementing a distributed message-sending system usin...
"Key considerations in implementing a distributed message-sending system usin...Fwdays
 
DevOps Fest 2020. Володимир Мельник. TuchaKube - перша українська DevOps/Host...
DevOps Fest 2020. Володимир Мельник. TuchaKube - перша українська DevOps/Host...DevOps Fest 2020. Володимир Мельник. TuchaKube - перша українська DevOps/Host...
DevOps Fest 2020. Володимир Мельник. TuchaKube - перша українська DevOps/Host...DevOps_Fest
 
Web service lecture
Web service lectureWeb service lecture
Web service lectureeleksdev
 
Real Time Transactions Ukr Final
Real Time Transactions Ukr FinalReal Time Transactions Ukr Final
Real Time Transactions Ukr Finalcynetvvd
 
10 asp.net
10 asp.net 10 asp.net
10 asp.net eleksdev
 
Version control
Version controlVersion control
Version controleleksdev
 
Aspnet core
Aspnet coreAspnet core
Aspnet coreeleksdev
 

Similar to Алексей Кириченко. "Как не потерять миллион". IT-пятница, сентябрь 2018 (10)

ASP.Net basics
ASP.Net basics ASP.Net basics
ASP.Net basics
 
"Key considerations in implementing a distributed message-sending system usin...
"Key considerations in implementing a distributed message-sending system usin..."Key considerations in implementing a distributed message-sending system usin...
"Key considerations in implementing a distributed message-sending system usin...
 
вашенюк
вашенюквашенюк
вашенюк
 
DevOps Fest 2020. Володимир Мельник. TuchaKube - перша українська DevOps/Host...
DevOps Fest 2020. Володимир Мельник. TuchaKube - перша українська DevOps/Host...DevOps Fest 2020. Володимир Мельник. TuchaKube - перша українська DevOps/Host...
DevOps Fest 2020. Володимир Мельник. TuchaKube - перша українська DevOps/Host...
 
Web service lecture
Web service lectureWeb service lecture
Web service lecture
 
Real Time Transactions Ukr Final
Real Time Transactions Ukr FinalReal Time Transactions Ukr Final
Real Time Transactions Ukr Final
 
10 asp.net
10 asp.net 10 asp.net
10 asp.net
 
Version control
Version controlVersion control
Version control
 
The Revenant: Legend of ProZorro
The Revenant: Legend of ProZorroThe Revenant: Legend of ProZorro
The Revenant: Legend of ProZorro
 
Aspnet core
Aspnet coreAspnet core
Aspnet core
 

Алексей Кириченко. "Как не потерять миллион". IT-пятница, сентябрь 2018

  • 1. ЯК НЕ ВТРАТИТИ МІЛЬЙОН: ПОБУДОВА ВІДМОВОСТІЙКОГО КЛАСТЕРА ВИСОКОНАВАНТАЖЕНИХ ВЕБ- СЕРВЕРІВ ХМАРИ – ЦЕ Олексій Кириченко, GigaCloud
  • 2. Задача Особливість проекту • Створення відмовостійкого рішення для порталу великого веб-магазину – з гарантією доступності сервісу 24/7. • Перехід на нову архітектуру без зупинки сервісу. Вертикальна ІТ-архітектура з високою вірогідністю недоступності системи при апаратних збоях
  • 3. 1. Створення балансування на рівні мережі. 2. Резервування і балансування web-серверів. 3. Резервування і балансування бази даних. Етапи переходу на нову архітектуру
  • 4. Створення балансування на рівні мережі • Використовуємо сервіс HAProxy на серверах балансування, що знаходяться у різних дата-центрах • Зв'язок між серверами балансування й іншими сервісами забезпечується розтягнутим L2 доменом Ресурси 2 Гб дискового простору 4 ядра процессора з розрахунку на кожен сервер 256 Мб оперативної пам'яті
  • 5. Резервування і балансування web-серверів • Використовуємо сервер синхронізації lsyncd у режимі source-destination • Перезапускаємо кожен web-сервер із кластера • Проводимо резервування на рівні web-сервера, при цьому навантаження розподіляється між серверами Ресурси х2 дисковий простір (додатково) ½ процесорної потужності з завантаженням 60-70% з розрахунку на кожен сервер ½ оперативної пам'яті
  • 6. Вхідна інформація про базу даних Співвідношення операцій запис/читання 20/100 Загальний рівень операцій в секунду 75
  • 7. Резервування і балансування бази даних Її переваги: • безперервність доступу (відсутня необхідність ручного або автоматичного призначення нового основного сервера, а отже відсутні і втрати часу) • гарантія 100% збереження даних Вирішили використовувати архітектуру master + master Дозволяє обробити понад 1000 запитів запису+поновлення в секунду
  • 8. Резервування і балансування бази даних VS Переваги сервісу • підвищена стійкість • краще збереження цілісності даних після краху • відмінна сумісність з MyISAM НАШ ВЫБОР Готові рішення для архітектури master + master
  • 9. Балансування трафіку на сервери бази даних – універсальний балансувальник трафіку + додаткові налаштування для перевірки стану DB Встановлюємо на веб-сервери, а не на окремі віртуальні машини. • перевірка доступності кожної ноди за допомогою тестових запитів • виключення помилкової ноди до моменту відновлення коректної роботи • при розсинхронуванні вмикається режим роботи з однією нодою з максимальною версією реплікації • рівномірний розподіл запитів між усіма нодами • створення бекапів незалежно на кожній ноді Можливості
  • 10. Фізична схема підключення віртуальних машин
  • 11. Логічна схема підключення віртуальних машин