Когда наступает подходящее время для внедрения высокой доступности для веб-сайта?
Есть много статей о вариантах высокой доступности. Однако это не так очевидно, КОГДА самое подходящее время для перехода с одного сервера на конфигурацию высокой доступности.
Пожалуйста, рассмотрите мою ситуацию:
http://www.postjobfree.com это круглосуточный веб-сайт со значительным трафиком:
http://www.similarweb.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 долларов в месяц.
Что бы вы посоветовали?
Короткий ответ: когда время простоя или его риск обходятся вам дороже, чем высокая доступность.
По сути, это экономическое решение. Например. 8 тысяч долларов в месяц подразумевают, что простой на 2 часа обойдется вам в 22 доллара. Если вы можете настроить свою систему таким образом, чтобы перейти с нуля к полнофункциональному сайту за 2 часа, то высокая доступность принесет вам только 22 доллара сверх этого функционала.
Другими словами, вы можете сэкономить деньги до тех пор, пока у вас не будет 54 часов непреодолимого простоя в данном месяце.
Ваши заинтересованные стороны / представители бизнеса (которыми можете быть вы!) Должны решить
Потерю дохода легко оценить количественно: на остальное здесь невозможно ответить, извините ...
Я думаю, что большинство пользователей могут справиться с запланированными простоями. Учтите, что на ebay есть еженедельные обновления по вечерам в пятницу, и ставки в это время иногда не работают. Онлайн-банкинг моего (крупного австралийского) банка запланировал перебои в работе на несколько часов каждую неделю. Твиттер постоянно отключается. Heroku / EC2 недавно не работал несколько дней.
Я бы держал это в таком ракурсе: если вы действительно говорите всего 5 минут в месяц, вы неплохо справляетесь как системный администратор.
Вы уже упоминали Google как фактор с точки зрения индексации, но, возможно, также стоит учесть влияние задержки / отзывчивости сайта на SEO. Это черный ящик и все такое, и его так сложно измерить количественно - хотя, как бы то ни было, Мэтт Каттс считает, что это однопроцентник. Меня больше беспокоит репутация, как утверждали другие.
Имейте в виду, что высокая доступность, как и безопасность, - это не продукт, а процесс.
Например, репликация базы данных приведет вас только к тому моменту, когда каждое зеркало базы данных сможет продолжить работу самостоятельно, но вам также понадобится стратегия повторной синхронизации после замены отказавших компонентов.
Рассмотрим систему заказов в качестве примера: клиент отправляет заказ, и во время обработки физическая система, с которой он разговаривал, дает сбой после сохранения информации о заказе в своей локальной копии базы данных. Нетерпеливый покупатель снова нажимает «отправить» и перенаправляется на другой сервер, который принимает заказ. Если ваши базы данных повторно синхронизируются, просто воспроизводя отсутствующие операторы INSERT на другой стороне, то порядок будет дублироваться, что может быть не тем, что вам нужно.
Как предположил @Slartibartfast, все сводится к экономическому решению, однако я бы рекомендовал вам также запланировать здесь несколько лет в будущем. Если вы ожидаете, что тогда вам потребуется правильная настройка высокой доступности, то сейчас самое время выделить ресурсы для подготовительной работы.
Пока вы думаете об этом, я думаю, вы подумываете о создании страницы «кита неудачников».
Есть много способов сделать это, но комбинация aws из 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.