Коли настав час встановити високу доступність веб-сайту?

Коли настав час встановити високу доступність веб-сайту?

Існує безліч статей про параметри високої доступності. Це не так очевидно, проте КОЛИ саме час перейти з одного сервера на конфігурацію високої доступності.

Будь ласка, врахуйте мою ситуацію:
http://www.postjobfree.com - це цілодобовий веб-сайт із значним трафіком: http : //www.s подобниweb.com/website/
postjobfree.com

В даний час я запускаю його на одному сервері: і веб-сервер IIS 7.0, і SQL Server 2008 працюють на одній і тій же апаратній коробці.

Існує періодичний (~ один на місяць) ~ 5 хвилин простою, який зазвичай спричиняється перезавантаженням, необхідним деяким оновленням Windows Server. Зазвичай час простою планується і трапляється вночі. І все-таки це неприємно, адже Google Bot та деякі користувачі все ще активні вночі.

Поточний дохід веб-сайту становить близько $ 8 К / місяць.

Я розглядаю можливість переходу на конфігурацію з двома серверами (веб-ферма з 2 веб-серверів та кластер 2 серверів SQL, розміщених на двох апаратних серверах).

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

Мінуси:
1) Більше зусиль для налаштування та підтримки такої конфігурації.
2) Більш висока вартість хостингу. Замість ~ 600 доларів на місяць це становило б близько 1200 доларів на місяць.

Яка б ваша рекомендація?

Коротка відповідь: Коли час простою або ризик це коштує вам дорожче, ніж коштуватиме вам висока доступність.

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

Інакше кажучи, ви можете заощадити гроші, якщо / поки у вас не буде 54 години непередбачуваного простою в даному місяці.

Ваші зацікавлені сторони / ділові люди (якими ви можете бути!) Повинні вирішити

• прийнятна втрата доходу
• наслідки втрата репутації, респектабельності тощо
• прийнятна втрата даних ( мета точки відновлення )
• прийнятний час простою ( мета відновлення )

Втрату доходу легко оцінити кількісно: на решту не можна відповісти тут вибачте ...

Я думаю, що більшість користувачів можуть впоратися з деяким запланованим простоєм. Вважайте, що на ebay є щотижневі оновлення у п’ятничну ніч, а ставки навколо цього часом не працюють. Інтернет-банкінг мого (головного австралійського) банку має заплановані відключення годин на тиждень. Twitter постійно працює в режимі офлайн. Нещодавно Heroku / EC2 минув.

Я б тримав це в такому ракурсі, якщо ви справді говорите лише 5 хвилин на місяць, ви робите досить гарну роботу як систематик.

Ви вже згадували Google як фактор з точки зору індексації, але, можливо, варто також врахувати вплив, який може мати затримка / чутливість сайту на SEO. Це чорна скринька і все таке, що її важко оцінити - хоча для того, що вона варта, Метт Кеттс вважає це однопроцентним . Мене більше турбує репутація, як заявили інші.

Майте на увазі, що HA, як і безпека, - це не продукт, а швидше процес.

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

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

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

Поки ви думаєте про це, я думаю, ви розглядаєте можливість створення сторінки "невдалого кита".

Існує маса способів зробити це, але комбо комбінація route53 і s3 добре працює на моїх маленьких сайтах.

Я налаштовую домен за допомогою перевірок здоров’я, щоб у разі відмов DNS відправляв користувачів користувачам на статичну сторінку HTML, що сидить у s3; Витрати поруч нічого.

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

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

Дивіться: https://aws.amazon.com/blogs/aws/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting/ для посібника з його налаштування.

Соціальний відмову від DynDns http://dyn.com/managed-dns/social-failover/ - це щось подібне.

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

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

Щоб уникнути втрати даних, слід вивчити конфігурації Raid перед кластерами. Вам також слід налаштувати IP-режим відмови, щоб ви могли переходити з одного сервера на інший у разі катастрофи, не чекаючи поширення DNS.