Висока доступність сервера для малого бізнесу

Після того, як трохи злякалися сервера, який не з'явиться одного ранку, вищі вершини вирішили, що бізнесу потрібна висока доступність / збій через налаштування.

У нас є 5 основних серверів (4x Linux, 1x OpenBSD), всі з яких потрібно працювати для роботи компанії. Три сервери досить стандартні (Files / Web / Database), четвертий обробляє більшість мережевих маршрутизаторів та веб-проксі, тоді як п'ятий підтримує нашу телефонну систему та має нестандартне обладнання.

Мій начальник заявив, що час виходу з ладу на сервері повинен бути менше 30 хвилин.

Мій досвід у цій галузі відсутній (я просто програміст, якого "підвищили"), тому я думаю, що моє питання дійсно зводиться до:

• Це щось, що навіть повинен намагатися хтось із середніми навичками сервера та адміністратора. Якщо так, то що я повинен читати, і з ким мені говорити?

Спасибі.

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

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

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

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

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

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

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

"Ця дорога призводить до сильного болю і болю ..."

Отже, який план безперервності вашого бізнесу? Ви плануєте відновлення після стихійних лих?

Ви це обговорювали? Це записали? ТЕСТУВАНО ЦЕ?

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

Отже, що насправді було "больовою точкою", яку вони відчували того ранку?

Це було?

• Телефони перестали працювати? Досить важлива (і видима) проблема. І так - для цього знадобиться "рішення", але, сподіваємось, це передбачено угодою про підтримку?
• Помилка веб-сайту? Гаразд - Добре помітний, але не несподіваний, і якщо у вас є ВЕЛИЧЕЗНА присутність в Інтернеті, це не так важливо. Гаразд, щоб цей сервер був вимкнений на кілька годин.
• Сервер бази даних вниз? Страшно ... Сподіваюся, у вас хороші резервні копії! Не втрачайте дані, інакше його бізнес НЕ провалиться. Але поки дані захищені, це важливий сервер і повинен мати план відновлення.
• Файл та друк (і внутрішні програми тощо). Це ПДФО для більшості людей, оскільки вони будуть сидіти і нічого не робитимуть за ранок, коли ви це поправите.

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

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

Можливо, багато проблем було БЕЗПЕЧЕНО. Вони не мали поняття, що така проблема може статися (і наскільки сервери важливі для їхнього бізнесу), і ви насправді не знали, що робите (?) З довірою?

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

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

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

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

Якщо ми почнемо з маршрутизації / веб-проксі-сервера, це, мабуть, найпростіше, оскільки їх не буде реальним станом, який потрібно зберігати у самій коробці. Тому просто дістаньте дублікат того самого поля і налаштуйте його однаково. Я б і надалі підключався до сегменту локальної мережі, і припускаючи, що Інтернет є на іншому інтерфейсі, міняйте кабелі, якщо їх не вдалося. З точки зору маршрутизації, ви встановлюєте всіх клієнтів, які ви використовуєте, щоб націлювати на .1 адресу (VIP) за маршрутом за замовчуванням, а проксі-сервер надає серверу A адресу .2 та серверу B адресу .3. Таким чином, ними можна керувати для оновлення конфігурації (стосується обох). І все, що вам потрібно зробити, щоб вийти з ладу, - це видалити призначення .1 IP з .2 та перенести його на .3 та перенести підключення до Інтернету до іншого інтерфейсу. Це не дуже складно, легко зробити і зрозуміти, і коштує додаткове обладнання другої коробки. Якщо ви можете отримати надмірність в Інтернеті, ви можете додати складності та отримати автоматичну відмову, використовуючи щось на зразок VRRP.

Без конкретики важко сказати, але ти веб-сервер може бути таким же простим. Додайте другий сервер з Ідентичною конфігурацією, створіть vIP між двома та перемістіть VIP до резервної копії за умови відмови. Я, як правило, не заперечую, якщо стан сеансу втрачено в режимі відмови (це критична проблема, щоб викликати аварію). Тож якщо користувачам доведеться знову входити в систему, нічого страшного. Знову ж таки, vrrp може бути використаний для автоматичного відмови.

Перейшовши на вашу БД, це значно складніше. Більшість БД мають якусь первинну / вторинну модель, де ви створюєте резервну копію оригінальної БД у вторинну, а потім копіюєте всі журнали транзакцій або зміни БД у вторинну. Знову ж таки, ви можете комбінувати це з VIP-адресами для додатків / користувачів, які фактично отримують доступ до БД. Однак аварійний перебіг ускладнюється. Залежно від несправності основного, можливо, вам потрібно буде фактично запустити накопичувачі та працювати, щоб копіювати та залишати журнали транзакцій. Потім піднесіть вторинну активну. Якщо ви можете терпіти деякі втрачені дані, ви можете вивести вторинну активну відразу. Після відмови, сервер B тепер стає основним, і ви працюєте над тим, щоб відновити сервер A і перетворити його в нову резервну копію, щоб він був готовий до виходу з ладу, коли з сервером b з часом виникнуть проблеми.

Файлові сервери завжди є найважчою частиною, оскільки на відміну від БД, набагато складніше отримати вбудовану функцію файлової системи. Однак деякого рівня стійкості можна досягти, маючи другий сервер і просто написати сценарій, який сканує файлову систему на предмет змін та скопіює будь-які нові файли, щоб ви були вторинними. Ви в основному можете запустити rsync на кроні, я вважаю, що це зробити. Знову ж таки, ви використовуєте VIP, який ви надаєте користувачам, і ви переходите, якщо ви не працюєте на відмову. У вашому сценарії я дуже рекомендую вам перевірити, щоб переконатися, що система є власником VIP, перш ніж передавати файли. Ви насправді дуже не хочете, щоб rsync виконувався в неправильному напрямку та переписував будь-які зміни, які ви вносите користувачам. Це може втратити деякі файли, якщо їх помилка,

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

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

Я працюю в телекомунікаціях, і наше обладнання дуже надлишкове, включаючи в більшості випадків географічну надмірність. Наша помилка № 1 - це надмірність не перевіряється після змін, і користувачі, які вносять зміни, які не знають, як працює модель надмірності. Однак у нас є додаткова проблема, що все наше обладнання потребує підтримки автоматичного відмови протягом не більше ніж декількох секунд. Ви можете терпіти ручне втручання у відмовників, якщо вам потрібно буде бути лише 30 - 60 хвилин. Вам просто потрібно бути готовим. Удачі.

Усі інші бали чудові, тому лише кілька коментарів.

Гарантувати 30 хвилин неможливо, особливо на все. Ви можете сказати, що це ціль, але це не може бути гарантією, оскільки завжди є X-фактор. У вас може бути 2 лінії провайдера, і вантажівка врізається в будівлю, і виводить їх обох, тому що ви не думали, що їх спрямованість з протилежних кінців будівлі має значення - один із прикладів.

Для початку варто подвоїти все. У вас є 5 серверів, тому вам потрібно подвоїти це. Це не потрібно, щоб все було на апаратному забезпеченні, ви можете віртуалізуватися, але ви бачите, що я маю на увазі. Крім того, все повинно бути в курсі HA, що також збільшить витрати, можливо, ви дізнаєтесь, що вам доведеться замінити свій роутер на новий, і вам потрібно 2 з них. Не забудьте подвоїти джерела живлення та отримати генератор, тому що ви не можете гарантувати, що енергокомпанія відновиться протягом 30 хвилин.

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

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

З’ясуйте, які саме послуги

критичні (зупинки бізнесу)

важливо (бізнес сповільнюється)

розпорядок (бізнес може на деякий час обійтися без цього).

Наприклад, ваші телефони телефонного центру є критично важливими, тому, можливо, варто придбати другий сервер і другий провайдер, а середній показник відключення електроенергії становить близько 15 хвилин, тому ми отримаємо ДБЖ, що триватиме 60 хвилин (не забудьте і робочі станції). Тепер скажемо, що ERP важливий лише для того, що означає, що ви можете функціонувати без нього трохи. Можливо, користувачі вашого телефонного центру використовують його, але якщо він знищений, вони можуть повернутися до ручки та паперу чи блокнота, а потім оновити ERP після. Процедура цього, якщо він знижується, може виявитися дешевшою, ніж намагатися зробити це критичною послугою. І рутинні можуть бути чимось на зразок принтерів, добре, це біль, але ми можемо виправитись на пару днів, якщо всі вони знизяться.

Це також дає наказ виправити речі, якщо s ** t дійсно потрапить у вентилятор одного дня :)

Це можливо? Звичайно. Це доступно? Можливо, це не для "малого бізнесу", особливо якщо у вас є начальник, який дає вам довільні номери, за якими можна працювати, і він вимагає високої доступності від ІТ-відділу, який складається з депутованого програміста (його бачили багато разів в інших місцях, і це ніколи підходить для вашого рівня стресу, якщо ваша ситуація була схожа на їхню).

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

Згадане вами обладнання для системи дзвінків - це спеціалізоване обладнання, і ви нагадали, що це центр обробки дзвінків. Ви повинні поговорити з продавцем про варіанти, щоб зробити це зайвим. Гуфінг з цим може в першу чергу втратити підтримку.

В інших системах ви, швидше за все, можете отримати надмірність, інвестуючи в рішення типу VMWare (або Hyper-V або XenServer, але я спершу роздивлюся б VMware та XenServer). Тоді ви можете подивитися на отримання SAN, пару надійних серверів із швидкими мережевими комутаторами та використовувати LiveMotion для переміщення віртуалізованих серверів між апаратними серверами, якщо виникає збій, а також збалансувати деяке навантаження між серверами у міру виникнення потреби.

Ви згадали, що в цих системах працює Linux. Отримавши гроші на отримання декількох серверів, ви можете замість цього налаштувати DRBD з програмою серцебиття та STONITH для копіювання даних між серверами та передачі, коли один стає недоступним; ви б дивилися на налаштування системи, де ви буквально дублювали кожен сервер, а також вдвічі збільшували енергоспоживання та тепловіддачу в серверній залі (якщо у вас є серверна кімната). Це можна зробити за рахунок апаратних засобів та вашої розумності. Плюс вам доведеться протестувати його, у вас буде час простою під час його налаштування, і ви все ще маєте можливість, що він не працюватиме часом, оскільки все ще існує можливість вирізання проблем, про які потрібно подбати (розділити мозок, наприклад).

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

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

Те, що вони говорять вам зробити це, і ви говорите, що ви "просто програміст, якого" просували ", і у вас є PHB, який говорить вам про те, щоб дати звільнення з максимальним часом відмови 30 хвилин, це те, що ви добрі до струмка.