Когда подходящее время для введения высокой доступности для веб-сайта?

16

Есть много статей о вариантах высокой доступности. Это не так очевидно, однако, КОГДА самое время переключиться с одного сервера на конфигурацию высокой доступности.

Пожалуйста, рассмотрите мою ситуацию:
http://www.postjobfree.com - это круглосуточный веб-сайт со значительным трафиком:
http://www.similweb.com/website/postjobfree.com

В настоящее время я запускаю его на одном сервере: и веб-сервер IIS 7.0, и SQL Server 2008 работают на одном аппаратном блоке.

Время от времени (~ один в месяц) ~ 5 минут простоя, как правило, вызвано перезагрузкой, необходимой для некоторых обновлений Windows Server. Обычно время простоя запланировано и происходит ночью. Тем не менее, это неприятно, потому что Google Bot и некоторые пользователи все еще активны ночью.

Текущий доход веб-сайта составляет около $ 8K / месяц.

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

Плюсы:
1) Высокая доступность (теоретически без простоев). Даже если один из серверов выйдет из строя - другой сервер вступит во владение.
2) Без потери данных: без кластера SQL может быть потеряно до одного дня данных в случае аппаратного сбоя (мы делаем ежедневное резервное копирование).

Минусы:
1) Больше усилий по настройке и поддержке такой конфигурации.
2) Более высокая стоимость хостинга. Вместо ~ 600 долларов в месяц это будет около 1200 долларов в месяц.

Что бы вы посоветовали?

— Денис Горелик
источник

Ответ на мой вопрос может повлиять на развитие. Например, я могу рассмотреть возможность разделения базы данных на части и хранить данные, требующие высокой надежности (ввод данных пользователем), отдельно от данных, требующих высокой производительности (расчеты).

2

Привет, Деннис, на самом деле это не рекомендация, поэтому я добавил это в качестве комментария, но ваши затраты на хостинг кажутся довольно высокими для одного сервера Windows? Я предполагаю, что это полностью выделенный сервер (не виртуальная машина), но даже в этом случае вам стоит подумать о половине стоимости приличного сервера спецификаций с 8 ГБ ОЗУ, хорошим объемом дискового пространства и т. Д. Возможно, стоит поговорить с Ваша хостинговая компания о получении лучшей цены.

— Эван Лейт,

6

Я думаю, что высокая доступность должна быть запланирована с первого момента концепции проекта.

— Том О'Коннор

Эван, я хочу, чтобы мой веб-сайт работал быстро, поэтому у меня есть процессор Quad с 8 ГБ памяти и SDD-накопитель. Фактор стоимости лицензий на программное обеспечение (Windows, SQL Server), SSL и техподдержка. У вас есть хорошее решение с низкой ценой для этого? В настоящее время я использую Сервер Интеллект (при поддержке SoftLayer) для хостинга. Вы бы порекомендовали что-нибудь лучше?

— Денис Горелик

2

Обновление Windows идет с обновлениями безопасности. Если я не исправлю свой сервер, он может быть уязвим для атак. Какую частоту обновления вы бы порекомендовали для производственного сервера Windows?

— Деннис Горелик

15

Краткий ответ: когда время простоя или его риск стоят вам дороже, чем высокая доступность.

Это принципиально экономическое решение. В качестве примера. 8 тысяч долларов США в месяц означают, что отключение в течение 2 часов обойдется вам в 22 доллара. Если вы сможете настроить свою систему так, чтобы за 2 часа перейти с нуля к полнофункциональному сайту, то высокая доступность принесет вам всего лишь 22 доллара функциональности.

Другими словами, вы можете сэкономить деньги, если / до тех пор, пока у вас не останется 54 часа непревзойденного простоя в данном месяце.

— Слартибартфаст
источник

16

Вы должны учитывать риск для репутации тоже

— gbn

7

Стоимость часа простоя почти наверняка зависит от того, когда сервер выйдет из строя. Очень маловероятно, что транзакции будут равномерно распределены в течение 24 часов. Это более нормально происходить в течение нескольких часов пик, когда потери будут намного больше.

— Джон Гарденье

Slartibartfast, я понимаю ваш ответ таким образом: убедитесь, что время восстановления после катастрофического сбоя является разумным (несколько часов), потеря данных является разумным (несколько часов), и позвольте себе время от времени проводить короткие запланированные простои (по крайней мере, сейчас) , Это означало бы наличие ежедневных резервных копий, инкрементальных частичных резервных копий и сервера, доступного для восстановления всей этой конфигурации. Звучит правильно?

— Денис Горелик

Ответы: gbn: согласен; Я искал простое объяснение, но репутация могла легко стать существенным фактором. Джон Гарденерс: Конечно, но если сайт используется только по воскресеньям с 11:00 до 13:00, тогда запланированное время простоя не является проблемой, в то время как ценник в 2 тыс . Долл . США для внепланового 2-часового простоя right_then есть. В этот момент вы должны выяснить, насколько вероятен этот несвоевременный сбой (при доходах в 2 тыс. Долл. США) по сравнению с определенной платой в 600 долл. США в месяц за сервер addnl. Подсказка: если случайные сбои в критический период не происходят чаще, чем 4 раза в год, это того не стоит.

— Slartibartfast

Деннис Горелик: определитесь с рисками, от которых вы хотите защититься (например, потеря бизнеса во время обслуживания, потеря сервера, потеря центра обработки данных, учетная запись / безопасность / защита базы данных) и действуйте, чтобы защитить от них. В этом случае вы защищаете от простоя из-за технического обслуживания и непредсказуемого отказа (насколько я могу судить). То, что вы описываете, должно сработать, но имейте в виду, что вам не нужно владеть сервером, пока вы можете быть уверены, что сможете его приобрести и настроить в период восстановления.

— Slartibartfast

11

Ваши заинтересованные стороны / деловые люди (которые могут быть вами!) Должны решить

приемлемая потеря дохода
последствия потери репутации, респектабельности и т. д.
допустимая потеря данных ( цель точки восстановления )
допустимое время простоя (время восстановления )

Потерю дохода легко определить количественно: на остальное здесь нельзя ответить, извините ...

— ГБН
источник

2

Я думаю, что большинство пользователей могут справиться с небольшим количеством запланированных простоев. Учтите, что на ebay еженедельные обновления делаются по пятницам, а ставки вокруг них иногда не работают. У онлайн-банкинга моего (крупного австралийского) банка запланировано отключение по часам каждую неделю. Твиттер постоянно отключается. Heroku / EC2 в последнее время не работал.

Я бы придерживался этой точки зрения, если вы действительно говорите только 5 минут в месяц, вы делаете неплохую работу в качестве системного администратора.

— Крис
источник

1

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

1

Имейте в виду, что HA, как и безопасность, - это не продукт, а процесс.

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

Рассмотрим систему заказов в качестве примера: клиент отправляет заказ, и во время обработки происходит сбой физической системы, с которой он общался, после сохранения информации о заказе в его локальной копии базы данных. Нетерпелив, клиент снова нажимает «отправить» и направляется на другой сервер, который принимает заказ. Если ваши базы данных ресинхронизируются путем простого воспроизведения отсутствующих операторов INSERT на другой стороне, порядок будет дублирован, что может оказаться не тем, что вам нужно.

Как предложил @Slartibartfast, все сводится к экономическому решению, однако я бы порекомендовал вам также запланировать несколько лет в будущем здесь. Если вы ожидаете, что вам понадобится правильная настройка HA, то сейчас самое время выделить ресурсы для подготовительной работы.

— Саймон Рихтер
источник

1

Пока вы думаете об этом, я думаю, что вы подумываете о создании страницы «неудачного кита».

Есть много способов сделать это, но комбо aws-маршрутов для53 и 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 и у вас есть какой-то способ манипулировать ими программно.

— Нат
источник

Должны ли эти проверки работоспособности выполняться с того же сервера, на котором размещен DNS? Я не могу представить, как сделать условное обновление DNS.

— Денис Горелик

@DennisGorelik не обязательно, но ваши DNS-записи нуждаются в коротком TTL, и что бы вы ни делали, ваша проверка здоровья должна иметь возможность быстро изменять записи. Обновленный ответ с дополнительной информацией о том, как этого добиться.

— Нат

Короткий TTL для DNS в сочетании с зависимостью от проверки работоспособности может сделать систему в целом менее стабильной (она может переключаться, даже если основной сервер работает нормально). На самом деле это может ухудшить ситуацию для конечных пользователей, а не улучшить.

— Денис Горелик

Короткие TTL сами по себе не должны быть проблемой для любого приличного DNS-провайдера, и если вы устанавливаете довольно низкую планку для своих проверок работоспособности (например, Failover, если нет http 200 в течение 10 минут), тогда стабильность не является проблемой. В качестве альтернативы вы можете пропустить часть проверки здоровья и выполнить ручной переход. Это будет означать более длительный период времени, когда ваши пользователи получают «тайм-аут соединения» и другие уродливые ошибки, но нет вероятности ложных срабатываний.

— Нат

0

Рассматривали ли вы использовать что-то вроде EC2, которое позволит вам гибко масштабировать, а также свести на нет ваши минусы? В конечном итоге это экономическое решение, стоит ли использовать EC2 или нет, но, по крайней мере, это вариант для рассмотрения.

— Manku
источник

-2

Чтобы избежать потери данных, вы должны изучить конфигурации Raid перед кластерами. Вам также следует настроить Failover IP, который вы можете переключать с одного сервера на другой в случае аварии, не дожидаясь распространения DNS.

— YQT
источник

откуда это взялось? что заставляет вас думать, что на плакате уже не используется RAID?

— Chopper3

Chopper3. Все, что я сказал, - это то, что Raid решит его проблему потери данных.

— Yqt

2

Как? если один диск умер, но что если его контроллер

— выйдет из строя