Высокая доступность сервера для малого бизнеса

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

У нас есть 5 основных серверов (4 Linux и 1 OpenBSD), все из которых должны работать, чтобы компания работала. Три сервера являются достаточно стандартными (Files / Web / Database), четвертый обслуживает большинство сетевых маршрутов и веб-прокси, а пятый поддерживает нашу телефонную систему и имеет нестандартное оборудование.

Мой начальник заявил, что время оборота сервера не должно превышать 30 минут.

Мой опыт в этой области отсутствует (я просто программист, которого «повысили в должности»), поэтому я думаю, что мой вопрос действительно сводится к следующему:

• Это что-то, что даже должно быть предпринято кем-то со средними навыками администрирования сервера. Если так, что я должен читать, и с кем я должен говорить?

Благодарю.

Я думаю, что вы должны начать собирать цифры, чтобы описать стоимость, связанную с выполнением заявленного «требования», чтобы увидеть, попадает ли он даже в бюджет. Если вас не устраивают все «обычные» методы, которые будут использоваться для выполнения требования (отказоустойчивая кластеризация, гипервизоры с возможностью «горячей миграции» и т. Д.), То вам, вероятно, будет полезно найти консультанта, который сможет выручить

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

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

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

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

Интересно, задумался ли ваш начальник о сценариях катастрофических сбоев (ожоги зданий, наводнения, торнадо, кражи и т. Д.). Если это еще не запланировано, это будет прекрасной возможностью поработать над общим планированием непрерывности бизнеса и аварийным восстановлением.

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

«Эта дорога приводит к большой боли и боли ...»

Итак, каков План Непрерывности Вашего Бизнеса? У вас план аварийного восстановления?

Вы обсуждали это? Записано? ИСПЫТАЛ ЭТО?

Вам нужно правильно пообщаться с «вышестоящими» и действительно разобраться в требованиях к высокой доступности, потому что они разные для разных сервисов.

Так что же на самом деле было «болевым пунктом», который они чувствовали в то утро?

Это было?

• Телефоны перестали работать? Довольно серьезная (и видимая) проблема. И да - это понадобится «решение», но, надеюсь, это в соответствии с соглашением о поддержке?
• Веб-сайт не удалось? Хорошо - довольно хорошо видно, но не неожиданно, и если у вас ОГРОМНОЕ присутствие в сети, то это не так важно. ОК, чтобы отключить этот сервер на несколько часов.
• Сервер базы данных не работает? Страшно ... Надеюсь, у тебя хорошие резервные копии! Не потеряйте данные, иначе он потерпит неудачу. Но если данные защищены, то это важный сервер, который должен иметь план восстановления.
• Файл и печать (и внутренние приложения и т. Д.). Это PITA для большинства людей, так как они будут сидеть и ничего не делать в течение утра, пока вы это исправите.

Я полагаю, вы купили высококачественное оборудование для своих основных систем? Хорошо, потому что дешевизна оборудования - это ложная экономия, поскольку эти серверы поставляются с «двойным» оборудованием.

Я также предполагаю, что вы знаете, КАК перестраивать сервер, менять вентиляторы, блоки питания, устанавливать сервер в стойку, настраивать сети с двумя путями в резервные коммутаторы? Вы сделали это достаточно раз, чтобы понять, что работает, а что нет, что нормально и что ошибочно? Если нет, то получите помощь и обучение (или хотя бы практику и опыт).

Может быть, большая проблема была в страхе. У них не было подсказки, что такая проблема может возникнуть (и насколько важны серверы для их бизнеса), и вы действительно не знали, что делаете (?) Проблема с доверием?

Вы должны понять все вышеперечисленное правильно, ПРЕЖДЕ чем идти по очень дорогому маршруту HA. Может ли бизнес позволить себе это дорогое оборудование (и большая часть его, по определению, будет использоваться только в случае отказа и часто никогда не будет использоваться!)

У Эвана есть некоторые хорошие моменты, но вот, возможно, некоторые конкретные экономически эффективные способы получить время восстановления до 1 часа перед лицом сбоев.

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

Во-первых, освоиться с мыслью о виртуальном IP. Это IP-адрес, с которым пользователи будут общаться, но он может находиться на любом сервере, которому вы его предоставляете. Это IP-адрес вашего пользователя, с которым приложения захотят общаться. И это будет самым полезным для ультимативно любого решения, к которому вы стремитесь. Наличие VIP означает, что вам не нужно перенастраивать какие-либо из приложений при сбое. Кроме того, имейте в виду, что наличие избыточного оборудования также увеличивает затраты на администрирование, делая два обновления конфигурации вместо 1.

Если мы начнем с вашего сервера маршрутизации / веб-прокси, он, вероятно, будет самым простым, поскольку он не будет иметь никакого реального состояния, которое нужно хранить на самой коробке. Так что просто получите дубликат одного и того же ящика и настройте его так же. Я бы оставил оба подключенных в сегменте локальной сети, и, если вы подключены к другому интерфейсу, подключите кабели, если они неисправны. С точки зрения маршрутизации вы настраиваете все свои локальные клиенты на адрес .1 (VIP) для своего маршрута по умолчанию, а прокси-сервер дает серверу A адрес .2, а серверу B адрес .3. Таким образом, ими обоими можно управлять для обновлений конфигурации (относится к обоим). И все, что вам нужно сделать для восстановления после сбоя, это удалить IP-назначение .1 из .2 и переместить его в .3, а также перенести интернет-соединение на другой интерфейс. Это не очень сложно, легко сделать и понять, и стоит дополнительное оборудование второй коробки. Если вы можете получить избыточность на стороне Интернета, вы можете добавить некоторую сложность и получить автоматический переход на другой ресурс при помощи чего-то вроде VRRP.

Без подробностей сложно сказать, но ваш веб-сервер может быть таким же простым. Добавьте второй сервер с идентичной конфигурацией, создайте VIP между ними и переместите VIP в резервную копию в случае сбоя. Я вообще не против, если состояние сеанса теряется при аварийном переключении (это критическая проблема вызвать аварийное переключение). Так что, если пользователям придется войти снова, ничего страшного. Опять же, vrrp, вероятно, можно использовать для автоматического перехода на другой ресурс.

Переходя к вашей БД, это значительно сложнее. Большинство БД имеют своего рода первичную / вторичную модель, где вы резервируете исходную БД на вторичную, а затем копируете все журналы транзакций или изменения БД на вторичную. Опять же, вы можете комбинировать это с VIP для приложений / пользователей, фактически обращающихся к БД. Однако отработка отказа более сложна. В зависимости от сбоя первичной системы вам может потребоваться запустить и запустить диски для копирования и оставления журналов транзакций. Затем приведите вторичный актив. Если вы можете допустить потерю данных, вы можете сразу же активировать вторичный актив. После отработки отказа сервер B теперь является основным, и вы должны восстановить сервер A и превратить его в новую резервную копию, чтобы он был готов к сбоям, когда на сервере b в конечном итоге возникнут проблемы.

Файловые серверы - всегда самая сложная часть, поскольку в отличие от баз данных, гораздо сложнее получить встроенную функцию файловой системы. Тем не менее, некоторый уровень отказоустойчивости может быть достигнут с помощью второго сервера, и просто напишите сценарий, который сканирует файловую систему на наличие изменений и копирует любые новые файлы на ваш вторичный сервер. Вы можете запустить rsync на кроне, который я считаю, чтобы сделать это. Опять же, вы используете VIP, который вы даете пользователям, который вы перемещаете, если выполняете аварийное переключение. В вашем сценарии я настоятельно рекомендую вам проверить, чтобы убедиться, что система является владельцем VIP, прежде чем передавать файлы. Вы действительно действительно не хотите, чтобы rsync выполнялся в неправильном направлении и перезаписывал любые изменения, которые вносят пользователи. Это может привести к потере некоторых файлов в случае сбоя,

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

Несколько заключительных слов предупреждения. Убедитесь, что вы тщательно протестировали все настройки, с которыми собираетесь работать. Удостоверьтесь, что вы знаете, как отменить это без потери этой важной информации. Тестовый тестовый тест, чтобы убедиться, что он будет работать, когда вам это нужно. Убедитесь, что у вас есть процессы, позволяющие корректно применять изменения конфигурации, обновления программного обеспечения и т. Д. Как для основного, так и для резервного копирования. Хорошая новость заключается в том, что вы, вероятно, можете выполнять управляемое переключение при сбое, когда хотите отключить сервер для обновления и т. Д. Это не активно-активная установка, поэтому вы не представляете, будет ли работать вторичный сервер, когда вам это нужно.

Я работаю в сфере телекоммуникаций, и наше оборудование очень избыточно, в том числе в большинстве случаев географическое резервирование. Наша точка отказа номер 1 - избыточность не проверяется после изменений, а пользователи вносят изменения, которые не знают, как работает модель избыточности. Однако у нас есть дополнительная проблема: все наше оборудование должно поддерживать автоматический переход на другой ресурс в течение не более нескольких секунд. Вы можете терпеть ручное вмешательство при переходе на другой ресурс, если вам нужно только запустить его в течение 30 - 60 минут. Вам просто нужно быть готовым. Удачи.

Все остальные баллы отличные, поэтому просто пара комментариев.

30 минут невозможно гарантировать, особенно для всего. Вы можете сказать, что это цель, но это никак не может быть гарантией, потому что всегда есть X-фактор. У вас может быть 2 линии провайдера, и грузовик врезается в здание и вывозит их обоих, потому что вы не думаете, что их можно направить с противоположных концов здания, это один из примеров.

Как начало для оценки, удвойте все. У вас есть 5 серверов, так что вам нужно удвоить, это. Это не обязательно должно быть на аппаратном уровне, вы можете виртуализировать, но вы понимаете, что я имею в виду. Вдобавок ко всему, все должны быть осведомлены о высокой готовности, что также увеличит стоимость, вы можете узнать, что вам придется заменить ваш маршрутизатор на новый, и вам нужно 2 из них. Не забудьте удвоить подачу питания и получить генератор, потому что вы не можете гарантировать, что энергокомпания вернется в течение 30 минут.

Эти примеры думают, что это более или менее горячая резервная установка, о которой, я подозреваю, думает ваш начальник.

Что я нахожу лучше для малого бизнеса, так это разработать план восстановления и классификации всего.

Выясните, какие услуги

критический (бизнес останавливается)

важно (бизнес замедляется)

рутина (бизнес может обойтись без него на некоторое время).

Например, телефоны вашего колл-центра имеют решающее значение, поэтому, возможно, стоит купить второй сервер и второго интернет-провайдера, и среднее отключение электроэнергии составляет около 15 минут, поэтому мы получим ИБП, который будет работать 60 минут (не забудь и рабочие станции тоже). Теперь давайте скажем, что ERP важен только, то есть вы можете работать без него некоторое время. Может быть, люди из вашего колл-центра используют его, но если он не работает, они могут вернуться обратно к ручке, бумаге или блокноту, а затем обновить ERP. Процедура сделать это, если она не работает, может оказаться дешевле, чем попытаться сделать ее критически важной услугой А обычные из них могут быть чем-то вроде принтеров, да, это боль, но мы можем сделать это на пару дней, если они все рухнут.

Это также даст вам возможность исправить ситуацию, если s ** t действительно ударит фаната однажды :)

Является ли это возможным? Конечно. Это доступно? Вероятно, не для «малого бизнеса», особенно если у вас есть начальник, который дает вам произвольные числа, с помощью которых он работает, и он требует высокой доступности от ИТ-отдела, состоящего из опытного программиста (его видели много раз в других местах, и он никогда довольно для вашего уровня стресса, если ваша ситуация была как у них).

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

Упомянутое вами оборудование системы вызовов - это специализированное оборудование, на которое вы ссылались как на центр обработки вызовов. Вы должны поговорить с продавцом о возможностях сделать это излишним. Дурачиться с этим может лишиться поддержки в первую очередь.

В других системах вы, скорее всего, могли бы получить некоторую избыточность, вкладывая средства в решения типа VMWare (или Hyper-V или XenServer, но сначала я бы посмотрел на VMware и XenServer). Затем вы можете взглянуть на получение SAN, нескольких мощных серверов с быстрыми сетевыми коммутаторами и использовать LiveMotion для миграции виртуализированных серверов между аппаратными серверами в случае сбоя, а также для балансировки некоторой нагрузки между серверами по мере необходимости.

Вы упомянули, что используете Linux на этих системах. Имея деньги, чтобы получить несколько серверов, вы могли бы вместо этого взглянуть на настройку DRBD с помощью программы пульса и STONITH для репликации данных между серверами и принятия решения, когда один из них становится недоступным; вы бы хотели настроить систему, в которой вы буквально дублировали каждый сервер, а также удвоили свое энергопотребление и теплоотдачу в серверной комнате (если у вас есть серверная комната). Это можно сделать за счет оборудования и вашего здравомыслия. Кроме того, вам придется протестировать его, у вас будет время простоя при настройке, и у вас все еще есть вероятность того, что он не будет работать время от времени, так как все еще есть вероятность возникновения проблем, о которых нужно позаботиться (split мозг, например).

Последний план - заставить пару систем действовать как чистые системы и иметь действительно хороший план резервного копирования, который позволит вам восстановить данные в одной из «пустых» систем в случае смерти сервера. Наличие аппаратного обеспечения на месте даст вам несколько вариантов, если / когда сервер умрет; но у вас все еще будет некоторое время простоя при восстановлении данных, и вам нужны инструкции о том, как правильно установить приложения на новый сервер. В зависимости от того, насколько быстро вы работаете и насколько велики данные, время простоя может составлять от нескольких часов до суток или двух. Вы действительно есть рабочая, заведомо исправный резервного копирования для серверов, с целью восстановления на месте, да?

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

Тот факт, что они говорят вам сделать это, и вы говорите, что вы «просто программист, которого« продвинули », и у вас есть PHB, говорящий вам дать избыточность с максимальным временем отказа 30 минут, заключается в том, что вы добры до ручья.