Чому великі сайти використовують кілька серверів замість одного сервера з кращими характеристиками?

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

Я бачив потужний окремий сервер з такими специфікаціями:

• 2 x Xeon E5-2630v2 при 2,60 ГГц, всього 12 ядер, 24 потоки; 30 Мб
• 64 Гб ECC Рег. до 768 ГБ DDR3 при 1600 МГц
• 4 х 120 Гб серії Intel 520/530 (80 кВ випадковий IOPS, ~ 550 Мб / с)
• HP iLo4 Advanced з виділеним портом управління Ethernet.

Чому б не використати єдиний сервер з більш високими характеристиками, як, наприклад, 768 ГБ оперативної пам’яті, 20 ТБ + HDD, 4+ x Xeon? Які переваги використання багатьох серверів або недоліки використання одного сервера високої специфікації?

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

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

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

Більшість великих веб-сайтів використовують балансири навантаження та декілька серверів. Раніше я працював у TripAdvisor. Вони опублікували чудову статтю про архітектуру TripAdvisor та про те, як вони роблять її масштабованою на кількох серверах.

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

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

• Вікіпедія: Горизонтальне та вертикальне масштабування
• Думки IBM щодо хмари: як пояснити вертикальне та горизонтальне масштабування у хмарі
• Інтернап-відео: вертикальне та горизонтальне масштабування

Від бункера контр-адмірала Грейс:

Про будівництво більших комп’ютерів: "У піонерські дні вони використовували волів для важкого витягування, і коли один вол не міг зрушити колоду, вони не намагалися виростити більшого вола. Ми не повинні намагатися на великих комп'ютерах, але для більшої кількості комп'ютерів ".

джерело

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

• Розділення проблем: ви згадуєте кілька радикально різних систем: зворотні проксі-сервери, БД, сервери вмісту тощо. З точки зору технічного обслуговування та безпеки, очевидно, вигідно, щоб ці обов'язки були розповсюджені по різних системах, щоб вони могли запускати іншу ОС (версію) при необхідності можна оновлювати окремо і не впливати на інші послуги, коли вони ставлять під загрозу.
• Подача вмісту: це кінцева мета веб-сервера, і він добре піддається моделі розподілення. Системи можна дублювати та розповсюджувати географічно, щоб мінімізувати затримку міжміських зв’язків. Це також дозволяє скоротити . На великих веб-сайтах використовуються балансири завантаження (ще один набір серверів!), Щоб забезпечити автоматичну відмову, щоб постійно підтримувати послугу.

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

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

"Зважаючи на всі вимоги щодо доступності та продуктивності, ми не могли продовжувати обробку платежів за мейнфрейми,

Джерело: Адам Банкс, в ComputerWorldUK

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

• Масштабованість - існує велика різниця між єдиною серверною системою, що використовує спільну пам'ять для IPC, і багатосерверною системою, яка використовує мережу або кластеризацію. Однак різниця між двома серверами і 200 значно менша - якщо ви створили систему, яка масштабує, ви можете масштабувати її МНОГО більше, перш ніж виникнуть проблеми ... і якщо у вас є, то насправді немає необхідності у величезному одному сервері на першому місці.

• Стійкість - один сервер - це місце, яке може адмініструвати один адміністратор. Або є фізична проблема, яка означає, що обслуговування цілого шматка олова перервано. (Витік води Datacentre, хтось врізається у стійку і перебиває її, таку річ). Кілька серверів можуть бути розподілені в центрі обробки даних, а ще краще географічно розподілені. І якщо ви вже розповсюджуєте свою програму, масштабування на “середніх” машинах майже завжди дешевше, ніж та сама кількість процесора / пам'яті / вводу-виводу на меншій кількості великих машин.

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

Візьмемо проблему в невеликих масштабах. Крихітний офіс з одним сервером, на якому працює електронна пошта, ActiveDirectory, спільний доступ до файлів та веб-сайт компанії.

Хакери потрапили на нього, і вам доведеться перезавантажити, тому що IIS заплутаний. Або Exchange потребує оновлення та перезавантаження. Або пошкоджено Active Directory.

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

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

Це стара приказка "не клади всі яйця в один кошик"

Тепер ця філософія застосовується до веб-серверів. Якщо у мене є лише один веб-сервер і я публікую свій веб-додаток (новий MyFaceLink.com), і він стає дуже популярним, у мене виникають нові проблеми. Я не можу знімати сайт для обслуговування, поки користувачі на ньому. І якщо вона виходить з ладу або я отримую занадто багато користувачів, я шлагуюсь. Навіть найбільший у світі єдиний сервер буде переповнений мільярдними перетворювачами FB, що надходять.

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

Найпростіше, справа не в ціні мега-сервера або в тому, чи може він справді впоратися з навантаженням (хоча це може бути). Йдеться про єдину точку відмови. Після того, як бізнес достатньо зайнятий і відбувається 24x7 замість того, щоб 5 користувачів працювали 8-5, простої не прийнятні. Планові відключення складніше запланувати. Отже, ви розносите навантаження.

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

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