Я хочу разместить (разместить в одном месте) услугу на Pier1, Q9 или другом подобном хостинге.
Лучше ли размещать оборудование для аварийного переключения в отдельные шкафы и, по вашему опыту, разрешит ли это хостинг-провайдер?
Меня беспокоит, что если что-то случится, скажем, загорится шкаф или недовольный арендатор стеллажа выльет свой кокс на серверы, оба моих стека высокой доступности будут скомпрометированы.
По вашему опыту, если я помещу их в отдельные шкафы, могут ли они находиться в одной подсети, или это противоречит политике хостинга, когда я прокладываю кабель из одного шкафа в другой?
Или дело в том, что такого рода события никогда не происходят, и я должен перестать беспокоиться?
Изменить: это очень ценное для бизнеса веб-приложение без сохранения состояния, где секунды простоя будут очень пагубными.
Сбой питания одной стойки встречается чаще, чем большинство других проблем, которые вы перечислили: выскакивание одного блока PDU или перегрузка цепи ... У меня такое случалось несколько раз, но ни одна из других перечисленных вами проблем .
В идеале ваше решение «высокой доступности» использует два разных центра обработки данных. (например, две зоны в регионе AWS)
Не обязательно. Это зависит от того, от каких ситуаций вы действительно хотите защититься.
У меня было несколько сред, в которых стратегия высокой доступности заключалась в создании параллельных стеков приложений в нескольких шкафах. Это означало все уровни приложения / службы; Коммутация, межсетевые экраны и т. д. присутствовали в двух шкафах, так что мы могли потерять одну стойку (или любой компонент внутри) без ущерба для доступности приложений.
Вы не указываете объем или природу вашего приложения. Более подробная информация поможет там. Но если вы говорите о чем-то небольшом, например об одном веб-сервере, в этом нет необходимости. Географическое разделение, аварийное переключение DNS и обеспечение внутреннего резервирования отдельных серверов (два источника питания, резервные вентиляторы, RAID) будут хорошим началом.
Прокладка кабелей между шкафами (кросс-соединения) внутри объекта не редкость. Обычно это результат невозможности получить непрерывное пространство. Но я бы не стал беспокоиться о том, что техник проливает жидкий напиток на вашу стойку или огонь ... Хотя, компонентные пожары жестяная банка происходить... но у меня был весь стек инфраструктуры аварийного переключения, чтобы избежать простоев.
Это зависит от требований высокой доступности вашего сервиса.
Если услуга не так важна для бизнеса, вероятно, нет смысла разделять узлы кластера между шкафами, особенно если окружающая инфраструктура, такая как основная сеть, балансировщики нагрузки и т. Д., Также разделены.
В услугах, представляющих большую ценность для бизнеса, разделение узлов отказоустойчивого кластера на отдельные топочные камеры является обычной практикой, и я рекомендую сделать это, если бизнес считает это целесообразным и готов заплатить цену.
Да, хостинг-провайдер позволит вам это сделать, если только он не один из самых маленьких и просто не имеет нескольких кабинетов.
Обычно вы не прокладываете собственные кабели между шкафами. Провайдер предлагает соединение между шкафами как услугу, и ваша основная сеть соединена с ним, или провайдер может также предлагать сеть как услугу.
Узлы в кластере могут использовать одну и ту же VLAN, которая по-прежнему остается SPOF в дополнение к самой технологии кластеризации и, вероятно, также к общему хранилищу. Чтобы предотвратить сбой служб в этих компонентах, вам нужно будет самостоятельно создать систему аварийного восстановления, которая обычно расположена достаточно географически и в которой служба асинхронно зеркалируется.
Это зависит. Ваши опасения разумны, хотя проблемы, которые вы описываете, редки.
Я бы сказал, что, безусловно, лучше иметь резервный блок в другой стойке, если не в другом здании / городе. Я не уверен, что трачу лишние деньги только на то, чтобы разместить резервный сервер в соседней стойке. Но, если стоимость такая же, это не повредит.
Хостинг-провайдеры не позволят вам прокладывать собственный кабель между шкафами. Но они поместят ваши два сетевых порта (по одному в каждом шкафу) в одну и ту же VLAN для вас, поэтому вы можете использовать одну и ту же подсеть, если это важно для вас.
Только вы можете решить, чего для вас стоит неудача. Как только вы это выясните, вы поймете, стоит ли об этом беспокоиться.
Риск пожара или саботажа, о которых вы упомянули, или других аналогичных экологических проблем вряд ли можно адекватно снизить, поместив вашу технику в стойки, расположенные достаточно близко, чтобы можно было проложить кабель между ними. Вспомните прошлогодние ураганы в районе Нью-Йорка: все центры обработки данных были отключены от сети.
Я бы посоветовал не слишком беспокоиться о высокой доступности, если у вас нет надлежащего разделения между членами кластера, или, по крайней мере, если вам ясно, что это реализуется для работы с обычным запуском ошибок (например, серверы ломается), а не что-то более экзотическое.
Ключевым моментом устойчивости является то, что она может быть настолько глубокой или неглубокой, насколько вы хотите (или для чего есть средства). Технический эквивалент этого - вы можете одноадресной или многоадресной рассылкой столько, сколько хотите (или у вас есть средства для этого).
Если вашему бизнесу требуется устойчивость, он определит, насколько эта устойчивость должна обеспечивать. Если у вас есть сеть, которой требуется 5 минут каждый день, то какое преимущество в устойчивости? Если ваша сеть - это больница и работает круглосуточно, без выходных, то у вас совершенно другая цель.
Я работал в среде, где бывшие сотрудники Cisco пытались диктовать требования и то, что я должен делать, и все же они неправильно понимали, глядя на инфраструктуру, а не на то, что требует бизнес / клиент.
Если вам нужна полная устойчивость, бизнес окупит затраты. Если нет, не беспокойтесь ..
Это действительно чужое решение.