Я работаю над системой клиент-сервер, где все клиенты в настоящее время отправляют свои транзакции по существу на один IP-адрес западного побережья, чтобы достичь того, что называется приложением «шлюз». Шлюз выполняет некоторый учет и отправляет каждую транзакцию на любой из нескольких серверов баз данных для окончательной обработки. Серверы возвращают свои результаты непосредственно клиенту (а не обратно через шлюз).
Планируется добавить второй шлюз на восточном побережье для резервирования и аварийного переключения. Обычно он находится только в режиме ожидания, он предназначен для того, чтобы взять на себя управление и стать фактическим шлюзом в случае отказа рабочего шлюза, по сути, классическая конфигурация. показано здесь.
Некоторые участники утверждают, что наличия только одного резервного шлюза недостаточно, и что мы также должны реализовать второй резервный шлюз, скажем, на Среднем Западе. Другие утверждают, что дополнительные затраты, сложность и управление двумя резервными станциями не нужны, и что одновременная недоступность шлюзов на обоих побережьях настолько маловероятна, что не вызывает беспокойства.
Что считается лучшей практикой? Какая степень избыточности (с точки зрения физически отдельных точек доступа, доступных клиентам) обычно считается номинальной? Достаточно ли распространены двойные отказы, чтобы часто сожалеть о наличии только одного резервного?
РЕДАКТИРОВАТЬ: Что касается «расчета» затрат и выгод для количества избыточности, которое мне нужно или хочу, я думаю, что лучше перефразировать мой вопрос так:
Где статистика, показывающая частоту, с которой географически разрозненная совокупность IP-адресов одновременно недоступна?
Другими словами, таблица вроде
On average, 1 west coast IP + 1 east cost IP
are simultaneously unreachable 1 day/year.
On average, 1 west IP + 1 east IP + 1 southern IP
are simultaneously unreachable 1 hr/year.
On average, 1 west IP + 1 east IP + 1 southern IP + 1 northern IP
are simultaneously unreachable 1 minute/year.
etc.
позволяет довольно легко выбрать желаемую избыточность, поскольку есть реальная основа для расчета затрат и производительности. (Я предполагаю, что «одновременно недоступны» должно означать «для значительного числа клиентов, случайным образом разбросанных по стране», поскольку один клиент может быть не в состоянии связаться с какими-либо серверами независимо от их количества из-за сбоя его собственной локальной сети.)
Однако без такой таблицы любые расчеты избыточности и производительности были бы лишь предположениями. Так: есть ли какие-либо источники реальных данных о доступности, на которых могут быть основаны такие расчеты? Или все просто догадываются, что им нужно, и расширяются по мере необходимости, когда узнают, что они занижены, или сокращают, если угадали больше?
Казалось бы, компании, предлагающие отказоустойчивые продукты, захотят собирать и продвигать такие данные. С другой стороны, возможно, данные покажут, что 99,99% отказоустойчивых клиентов вообще не нуждаются в избыточности. Например, если я могу работать в течение целого года, и мои восточный и западный IP-адреса никогда не будут одновременно недоступны, я не буду беспокоиться о добавлении среднего западного IP-адреса.
Я также понимаю, что существует различие между недоступностью IP-адреса из-за внешних сил по отношению к моему сайту и отключением IP-адреса из-за внутреннего сбоя моего сайта. Внутренние сбои (на моей стороне IP-адреса) относительно легко исправить. Внешние сбои (на стороне клиента IP-адреса, например, отключение Калифорнии из-за землетрясений или отключение Нью-Йорка во время урагана) я могу справиться, только имея дополнительные IP-адреса в другом географическом месте. Который это вероятность, которую я надеюсь определить количественно. На данный момент я склоняюсь к мнению, что вероятность того, что восточный и западный IP-адреса одновременно недоступны, слишком мала, чтобы о ней беспокоиться.
Что сказал @ HopelessN00b. Вы должны взвесить сырье Стоимость VS Выгода для себя.
Вам необходимо рассчитать:
Для этого нет лучшей практики.
Где статистика, показывающая частоту, с которой географически разрозненная совокупность IP-адресов одновременно недоступна?
Это тоже зависит от обстоятельств. Например, мы говорим о статистике для клиентов, у которых нет UPS, или их собственные Генератор? или даже две независимые линии электропередачи от отдельных подстанций?
Это тоже входит в уравнение. В нашей компании произошло отключение электроэнергии из-за полного отключения электроэнергии, которое было настолько продолжительным, что у нашего ИБП закончился заряд.
Мы приступили к покупке генератора для всего нашего центра обработки данных, который работает X часов, с возможностью подзарядки за счет сброса топлива во время чрезвычайных ситуаций, так что даже если локальная подсистема полностью выйдет из строя, мы можем продолжать работать почти бесконечно.
возможно, данные покажут, что 99,99% отказоустойчивых клиентов вообще не нуждаются в избыточности.
Полностью.
У меня есть клиенты, которые запускают критически важные ($$$) системы на одном сервере в одном месте, и их сервер надежен, потому что выполняет всего одну функцию. Чем меньше сложностей, тем лучше.
Это старая ироническая ситуация, когда вы добавляете решение аварийного восстановления, а затем испытываете больше сбоев, чем когда-либо прежде.
Как уже было сказано, здесь нет общей передовой практики на техническом уровне, кроме очевидного списка вещей. не делать.
Многие будут проинформированы обоими соглашениями об уровне обслуживания, которые у вас явно есть с вашими клиентами или которые, вероятно, будут приняты в их отрасли - важно, чтобы вы были уверены, что можете поддерживать это при любых обстоятельствах, кроме самых исключительных, и позволить себе любую необходимую компенсацию сделать, если случатся самые исключительные обстоятельства. Например, с некоторыми из наших клиентов у нас есть четырехчасовое окно восстановления, при этом 24-часовой дневной убыток является «приемлемым» (что очень легко обеспечить), для другого проекта, который работает в режиме реального времени, это время составляет десять и тридцать минут, и я могу представить себе критически важные службы и / или службы безопасности, имеющие гораздо более строгие ожидания, чем это.
Единственный общий совет, который я могу придумать, - это убедиться, что у вас есть основы всего, охватываемого до определенного уровня, прежде чем тратить время и деньги на один конкретный момент. Наличие самого избыточного отказоустойчивого уровня базы данных на планете не поможет вам, когда исчезнет одна публичная ссылка на вашу веб-ферму. Поэтому постарайтесь не защищать одну сторону системы чрезмерно за счет других.
Наш первый веб-сервер был запущен в городе X в 1995 году через соединение Centrex, которое было преобразовано в ISDN в 1998 году, а затем в DSL в 2001 году, когда мы также запустили второй статический адрес в городе Y в нескольких милях от нас для резервного копирования. Хотя мы использовали двух разных интернет-провайдеров, основная сеть была PacBell, теперь ATT. Наш объект в городе X был освобожден в 2003 году, и только город Y управлял нашим сервером до 2009 года, когда мы запустили другой статический адрес в городе Z, снова всего в нескольких милях от города Y, и оба Y и Z теперь даже используют одного и того же провайдера.
Насколько мы могли судить, за все эти годы наши IP-адреса никогда не были «внешне» (как вы выразились) недоступными. Очевидно, PacBell / ATT и наш интернет-провайдер всегда обладали достаточной избыточностью, чтобы всегда, по крайней мере, доставлять наши пакеты. «Внутренне» единственными проблемами, которые у нас были, были сбои питания, даже не сбои машин, и простого временного переключения указателей DNS между двумя местоположениями во время подобных инцидентов (на несколько дней, может быть, раз в пару лет) было достаточно для наши цели.
Если вы получите IP-адрес западного побережья и IP-адрес восточного побережья, я предсказываю, что ваши клиенты (как группа), вероятно, никогда не увидят, что эти адреса одновременно недоступны. Если оба места недоступны (другими словами, туда нельзя даже отправлять пакеты), то, вероятно, прибыл Армагеддон, и у вас все равно будут большие проблемы. Просто убедитесь, что у вас есть политики и процедуры (и протестированы), чтобы как можно скорее выполнить резервное копирование в случае внутреннего сбоя на любом из сайтов, и не беспокойтесь о получении третьего IP-адреса Среднего Запада, пока обстоятельства не докажут, что это действительно необходимо.