Немного напугав сервер, который однажды утром не встал, начальство решило, что бизнесу нужна настройка высокой доступности / аварийного переключения.
У нас есть 5 основных серверов (4x Linux, 1x OpenBSD), все из которых должны быть запущены для работы компании. Три сервера довольно стандартные (файлы / веб / база данных), четвертый обрабатывает большую часть сетевой маршрутизации и веб-прокси, а пятый поддерживает нашу телефонную систему и имеет нестандартное оборудование.
Мой босс заявил, что время восстановления после сбоя сервера должно составлять менее 30 минут.
У меня нет опыта в этой области (я просто программист, которого «повысили»), поэтому я полагаю, что мой вопрос действительно сводится к следующему:
Спасибо.
Я думаю, вам следует начать с того, чтобы собрать цифры, чтобы описать затраты, связанные с выполнением заявленного «требования», чтобы увидеть, укладывается ли оно вообще в бюджет. Если вас не устраивают все «обычные» методы, которые могут быть использованы для выполнения требований (отказоустойчивые кластеры, гипервизоры с возможностью «горячей миграции» и т. Д.), То вам, вероятно, следует найти консультанта, который сможет выручайте.
Это будет связано с определенными затратами, связанными с технико-экономическим обоснованием, но будет намного меньше, если вы обнаружите, что хорошее решение не соответствует заявленным требованиям (это означает, что ожидания должны быть более реалистичны со стороны руководства - или они нужно потратить больше денег), чем будет стоить сделать что-то наполовину бессмысленное, что в конечном итоге приведет к тому, что требования не будут выполнены, и в процессе будет потрачено много денег.
Похоже, ваш босс только что вытащил это число из воздуха. Возможно, он провел некоторый анализ и знает, какова стоимость часа, связанная с простоями различных систем, но я сомневаюсь в этом. Звучит как какая-то приземленная цифра, не привязанная к реальности. Я был бы удивлен, если бы все ваши системы нуждались в такой доступности. Возможно, в ходе изучения бизнеса вы обнаружите, что только часть функций должна иметь такую степень безотказной работы и отказоустойчивость (и, следовательно, такое решение в конечном итоге будет стоить дешевле). Я уверен, что телефоны и бизнес-приложения уже есть, но вы можете терпимо относиться к простою в некоторых других системах.
Мое чутье подсказывает, что вы, вероятно, выиграете в использовании технологий виртуализации для создания отказоустойчивой системы, основанной на миграции виртуальных машин между избыточным оборудованием. Будет ли это соответствовать вашему бюджету или нет, будет зависеть от вашего бизнеса, поскольку вам определенно понадобится какой-то тип SAN, чтобы это работало эффективно.
Однако не сбрасывайте со счетов «традиционную» отказоустойчивую кластеризацию. Там тоже определенно есть "выигрыши", если ваши приложения хорошо подходят для такой конфигурации.
Интересно, задумывался ли ваш начальник о сценариях катастрофических отказов (возгорание зданий, наводнение, торнадо, кража и т. Д.). Если это еще не запланировано, это будет прекрасная возможность поработать над общим планированием непрерывности бизнеса и аварийным восстановлением в чрезвычайных обстоятельствах.
Получите помощь от кого-нибудь, кто может прийти и изучить ваш бизнес и дать рекомендации. Вы не пожалеете.
«Эта дорога приносит много боли и боли ...»
Итак, каков план обеспечения непрерывности вашего бизнеса? Вы планируете аварийное восстановление?
Вы это обсуждали? Записал? ПРОВЕРИЛИ ЭТО?
Вам необходимо правильно поговорить с «высшими руководителями» и действительно разобраться в требованиях к высокой доступности, потому что они различаются для разных служб.
Так что же на самом деле было «болевой точкой», которую они почувствовали в то утро?
Это было?
Я полагаю, вы купили качественное оборудование для своих основных систем? Хорошо, потому что удешевление оборудования - ложная экономия, поскольку эти серверы поставляются с «двойным» оборудованием.
Я также предполагаю, что вы знаете, КАК перестроить сервер, поменять местами вентиляторы, блоки питания, установить сервер в стойку, сконфигурировать сети с двойным путём в резервные коммутаторы? Вы проделали это достаточно раз, чтобы понять, что работает, а что нет, что нормально, а что ошибочно? Если нет, то получите помощь и обучение (или хотя бы практику и опыт).
Может быть, во многом проблема заключалась в СТРАХЕ. Они не подозревали, что такая проблема может случиться (и насколько важны серверы для их бизнеса), а вы действительно не знали, что делаете (?) Проблема с доверием?
Вы должны выполнить все вышеперечисленное ДО того, как пойти по очень дорогому маршруту высокой доступности. Может ли бизнес позволить себе это дорогое оборудование (и большая часть его, по определению, будет использоваться только в случае отказа и часто никогда не будет использоваться!)
Эван говорит о некоторых хороших моментах, но, возможно, вот некоторые конкретные рентабельные способы сократить время восстановления после сбоя менее 1 часа.
Малый бизнес, скорее всего, означает небольшое оборудование, поэтому выполнение некоторых простых действий, которые на самом деле значительно повышают отказоустойчивость перед лицом проблем, может не обойтись. Основная идея - просто подготовить дополнительное оборудование.
Во-первых, представьте себе виртуальный IP-адрес. Это IP-адрес, с которым будут разговаривать пользователи, но он может находиться на любом сервере, которому вы его предоставите. Это IP-адрес, которым вы пользуетесь, и приложения захотят общаться с ним. И это будет наиболее полезным для любого решения, которое вы выберете. Наличие VIP означает, что вам не придется повторно настраивать какие-либо приложения при отказе. Кроме того, имейте в виду, что наличие избыточного оборудования также увеличивает накладные расходы на администрирование, выполняя два обновления конфигурации вместо одного.
Если мы начнем с того, что вы маршрутизируете / веб-прокси-сервер, это, вероятно, самый простой вариант, поскольку у них не будет никакого реального состояния, которое необходимо сохранить в самом ящике. Так что просто возьмите копию той же коробки и настройте ее так же. Я бы оставил оба подключенными к сегменту локальной сети, и если вы подключены к Интернету на другом интерфейсе, поменяйте кабели местами, если они вышли из строя. С точки зрения маршрутизации, вы настраиваете всех своих LAN-клиентов на целевой адрес .1 (VIP) для их маршрута по умолчанию, а прокси-сервер дает серверу A адрес .2, а серверу B - адрес .3. Таким образом, ими обоими можно управлять для обновлений конфигурации (применимо к обоим). И все, что вам нужно сделать для аварийного переключения, - это удалить назначение IP .1 из .2 и переместить его в .3, а также переместить интернет-соединение на другой интерфейс. Это не очень сложно, легко сделать и понять, и стоит дополнительное оборудование в виде второй коробки. Если вы можете получить избыточность на стороне Интернета, вы можете добавить некоторую сложность и получить автоматическое переключение при отказе, используя что-то вроде VRRP.
Без конкретики сложно сказать, но ваш веб-сервер может быть таким же простым. Добавьте второй сервер с идентичной конфигурацией, создайте между ними vIP и переместите VIP в резервную копию в случае сбоя. Обычно я не возражаю, если состояние сеанса будет потеряно при аварийном переключении (вызвать аварийное переключение - критическая проблема). Так что, если пользователям придется снова войти в систему, ничего страшного. Опять же, vrrp, вероятно, можно использовать для автоматического переключения при отказе.
Переходя к вашей БД, это значительно сложнее. Большинство БД имеют своего рода первичную / вторичную модель, в которой вы делаете резервную копию исходной БД на вторичную, а затем копируете все журналы транзакций или изменения БД на вторичную. Опять же, вы можете объединить это с VIP для приложений / пользователей, фактически обращающихся к БД. Однако аварийное переключение более сложно. В зависимости от сбоя основного вам может потребоваться запустить диски для копирования и оставшихся журналов транзакций. Затем приведите вторичный активный. Если вы можете терпеть потерю некоторых данных, вы можете сразу же включить вторичный активный. После аварийного переключения сервер B теперь является вашим основным, и ваша работа будет состоять в том, чтобы восстановить сервер A и превратить его в новую резервную копию, чтобы он был готов к отказу, когда на сервере b в конечном итоге возникнут проблемы.
Файловые серверы всегда являются самой сложной частью, поскольку, в отличие от БД, гораздо сложнее получить встроенную функцию файловой системы. Однако некоторого уровня отказоустойчивости можно достичь за счет наличия второго сервера и простого написания сценария, который сканирует файловую систему на предмет изменений и копирует любые новые файлы на ваш вторичный сервер. Вы можете запустить rsync на cron, который, как я полагаю, для этого. Опять же, вы используете VIP, который вы даете пользователям, который вы перемещаете, если выполняете аварийное переключение. В вашем сценарии я настоятельно рекомендую вам убедиться, что система является владельцем VIP, прежде чем передавать файлы. Вы действительно действительно не хотите, чтобы rsync выполнялся в неправильном направлении и перезаписывал любые изменения, которые вы вносите. Это может привести к потере некоторых файлов в случае их сбоя, а также не защитит пользователей от уничтожения файлов самостоятельно.
Я понятия не имею, что вы можете сделать со своей телефонной системой ... это действительно зависит от поставщика и того, как она настроена. У поставщика может быть готовое решение для обеспечения отказоустойчивости.
Несколько последних слов предупреждения. Убедитесь, что вы тщательно протестировали любую настройку, с которой собираетесь работать. Убедитесь, что вы знаете, как выполнить отказ, не теряя важной информации. Тестовый тестовый тест, чтобы убедиться, что он будет работать, когда вам это нужно. Убедитесь, что у вас есть процессы, позволяющие правильно применять изменения конфигурации, обновления программного обеспечения и т. Д. Как к основным, так и к резервным копиям. Хорошая новость в том, что вы, вероятно, можете выполнить управляемое переключение при отказе, когда вы хотите остановить сервер для обновления и т. Д. Это не активно-активная установка, поэтому вы не знаете, будет ли вторичный сервер работать, когда он вам нужен.
Я работаю в сфере телекоммуникаций, и наше оборудование очень избыточно, в том числе в большинстве случаев с географическим резервированием. Наша точка отказа номер 1 - это то, что избыточность не проверяется после изменений, и пользователи, вносящие изменения, не знают, как работает модель избыточности. Однако у нас есть дополнительная проблема, заключающаяся в том, что все наше оборудование должно поддерживать автоматическое переключение при отказе не более чем за несколько секунд. Вы можете терпеть ручное вмешательство при отработке отказа, если вам нужно только начать работу в течение 30-60 минут. Просто нужно быть готовым. Удачи.
Очки всех остальных хороши, так что всего пара комментариев.
30 минут гарантировать невозможно, особенно на все. Вы можете сказать, что это цель, но это никак не может быть гарантией, потому что всегда есть X-фактор. У вас может быть 2 линии Интернет-провайдера, и грузовик врезается в здание и выводит их из строя, потому что вы не думали, что их проложить с противоположных концов здания имеет значение - это один из примеров.
Для начала, удвойте все. У вас 5 серверов, поэтому вам нужно удвоить это. Необязательно, чтобы все было на оборудовании, вы можете виртуализировать, но вы понимаете, о чем я. Вдобавок ко всему, все должно быть осведомлено о HA, что также увеличит стоимость, вы можете обнаружить, что вам придется заменить свой маршрутизатор на новый, и вам нужно 2 из них. Не забудьте удвоить подачу мощности и получить генератор, потому что вы не можете гарантировать, что энергетическая компания вернется к работе в течение 30 минут.
Эти примеры думают, что это более или менее установка горячего резерва, о чем, я подозреваю, думает ваш босс.
Я считаю, что для малого бизнеса лучше разработать план восстановления и классификации всего.
Выясните, какие услуги
критический (бизнес останавливается)
важно (бизнес замедляется)
рутина (бизнес какое-то время обходится без нее).
Например, телефоны вашего центра обработки вызовов имеют решающее значение, поэтому, возможно, стоит купить второй сервер и второго провайдера, а ваше среднее отключение электроэнергии составляет около 15 минут, поэтому мы получим ИБП на это время на 60 минут (не про рабочие станции тоже забудь). Теперь предположим, что ERP важна только потому, что вы можете немного работать без нее. Возможно, сотрудники вашего центра обработки вызовов используют его, но если он не работает, они могут вернуться к ручке и бумаге или блокноту, а затем обновить ERP. Процедура, чтобы сделать это, если она не работает, может быть дешевле, чем попытка сделать ее критически важной услугой. И обычные могут быть чем-то вроде принтеров, ладно, это боль, но мы можем сделать это через пару дней, если они все выйдут из строя.
Это также дает вам приказ исправить вещи, если дерьмо однажды действительно ударит по поклоннику :)
Является ли это возможным? Конечно. Это доступно? Наверное, не для «малого бизнеса», особенно если у вас есть начальник, который дает вам произвольные числа для работы, и он требует высокой доступности от ИТ-отдела, состоящего из заместителя программиста (видел это много раз в других местах, и никогда не красиво для вашего уровня стресса, если ваша ситуация была такой же, как у них).
Отказоустойчивость возможна, но обычно требует избыточного оборудования, сетей SAN для обмена данными между серверами и т. Д. Другими словами, удачи в финансировании, если они не наймут специального администратора, который позаботится об этом.
Упомянутое вами оборудование системы обработки вызовов - это специализированное оборудование, и вы упомянули, что это центр обработки вызовов. Вам следует поговорить с поставщиком о вариантах, позволяющих сделать это избыточным. Если вы будете шутить с этим, это может вообще лишить вас поддержки.
В других системах вы, скорее всего, могли бы получить некоторую избыточность, вложив средства в решения типа VMWare (или Hyper-V или XenServer, но сначала я бы посмотрел на VMware и XenServer). Затем вы можете взглянуть на получение SAN, пары мощных серверов с быстрыми сетевыми коммутаторами и использовать LiveMotion для миграции виртуализированных серверов между аппаратными серверами в случае сбоя, а также для балансировки некоторой нагрузки между серверами по мере необходимости.
Вы упомянули, что используете Linux в этих системах. Имея деньги на приобретение нескольких серверов, вы могли бы вместо этого взглянуть на настройку DRBD с программой проверки пульса и STONITH для репликации данных между серверами и перехода к ним, когда один из них становится недоступным; вам нужно было бы создать систему, в которой вы буквально дублировали каждый сервер, а также удвоили потребление энергии и рассеивание тепла в серверной (если у вас есть серверная). Это можно сделать за счет стоимости оборудования и вашего рассудка. Кроме того, вам нужно будет протестировать его, у вас будет время простоя при его настройке, и у вас все еще есть вероятность, что он не будет работать время от времени, поскольку все еще существует вероятность возникновения проблем, о которых необходимо позаботиться (разделение мозг, например).
Последний план - заставить пару систем действовать как системы с чистого листа и иметь действительно хороший план резервного копирования, который позволит вам восстановить данные в одной из «пустых» систем в случае отказа сервера. Наличие оборудования на месте даст вам несколько вариантов, если / когда сервер умирает; но у вас все равно будет некоторое время простоя при восстановлении данных, и вам понадобятся инструкции о том, как правильно установить свои приложения на новый сервер. В зависимости от того, насколько быстро вы работаете и насколько объемны данные, время простоя может составлять от нескольких часов до одного-двух дней. Вы делать у вас есть работающая, заведомо исправная резервная копия для ваших серверов с планом восстановления, да?
Стоит ли вам попробовать? Моя первая реакция заключается в том, что если вы чешете голову при любом предложении или чувствуете ямку в животе, пытаясь обдумать это, то вам не следует. Вам потребуется консалтинговая компания, которая рассмотрит проблему, определит затраты и внедрит ее, или вам потребуется нанять специального системного администратора, который сделает это для вашей компании.
Тот факт, что вам говорят сделать это, а вы говорите, что вы «просто программист, которого« повысили », и у вас есть PHB, который говорит вам, что вам нужно обеспечить избыточность с максимальным временем отказа 30 минут, - это то, что вы любезны вверх по ручью.