Фоновый: Нам нужен сервер высокой доступности в небольшом офисе, и мы ищем DRBD, чтобы предоставить его. У нас есть только около 100 ГБ, которые должны быть на сервере высокой доступности, и нагрузка на сервер будет чрезвычайно низкой. Данные, вероятно, будут увеличиваться примерно на 10-25% в год, если мы будем архивировать старые офисные данные, и на 50-75% каждый год, если мы этого не сделаем.
Дело в том, что мы используем сочетание потребительского и корпоративного оборудования, что БУДЕТ проблемой, если мы не планируем это заранее; а готовые качественные серверы ДЕЙСТВИТЕЛЬНО выходят из строя, поэтому резервные серверы кажутся правильным решением.
План: Мы думаем, что было бы хорошо найти (2) из самых эффективных используемых серверов и синхронизировать их. Нам просто нужны серверы с поддержкой SATA / SAS и место для максимально возможного количества дисков по такой цене. Похоже, что эти серверы можно купить за 100-200 долларов (+ некоторые детали и дополнительные диски), если вы поймаете сделку.
Теоретически это означало бы, что сервер может выйти из строя, и если бы нам потребовались дни, чтобы добраться до него, пока у нас не было другого случайного сбоя, все продолжалось бы, пока наш ИТ-отдел (я) не смог бы добраться до него. Мы бы использовали Debian в качестве ОС.
Некоторые вопросы
(A) Как DRBD обрабатывает сбой привода или контроллера? То есть это показывает DRBD перед драйвером хранилища, так что же происходит, когда контроллер выходит из строя и записывает грязные данные, или диск выходит из строя, но не выходит из строя сразу? Отображаются ли данные на другом сервере или нет, и существует ли риск повреждения данных на серверах в подобных случаях?
(B) Каковы точки отказа для DRBD; это теоретически до тех пор, пока один сервер работает, проблем не возникает НИКОГДА. Но мы знаем, что есть проблемы, так каковы же режимы отказа при использовании DRBD, поскольку большинство из них теоретически должно быть программным?
Если у нас будет два сервера для этого, было бы разумно запускать виртуальные машины на каждом с MYSQL и Apache для репликации базы данных и веб-сервера? (Я так предполагаю)
Достаточно ли надежен DRBD? Если нет, то является ли ненадежность изолированной для определенных задач или она более случайна. При поиске были обнаружены люди с различными проблемами, но это Интернет, в котором, по-видимому, больше плохой информации, чем хорошей.
Если данные синхронизируются по локальной сети, использует ли DRBD удвоенную пропускную способность? То есть, должны ли мы удвоить количество NICS и провести агрегацию каналов и транкинг? Затем, возможно, разместите их на отдельных маршрутизаторах в отдельных цепях и ИБП в отдельных комнатах, и теперь у вас действительно есть некоторое резервирование!
Это слишком безумно для офиса с точки зрения управления серверами? Есть ли более простая альтернатива в реальном времени (если DRBD кажется простым в теории).
У нас уже есть сервер. Так что мне кажется, что второй ИСПОЛЬЗУЕМЫЙ сервер с выделенным диском для DRBD можно легко приобрести за 150–250 долларов при разумных покупках. Добавьте второй маршрутизатор, дополнительные диски, дополнительные сетевые адаптеры (бывшие в употреблении) и (2) ИБП, и мы говорим о $ 1000 +/-. Это относительно дешево! И я надеюсь, что это позволит нам выиграть время во время сбоя сервера. В наши дни сбои дисков кажутся более простой проблемой с RAID. Это другие аппаратные сбои, такие как контроллеры, память или блоки питания, которые могут потребовать простоя для диагностики и исправления, которые являются проблемой.
Резервные серверы для нас означают, что используемое оборудование становится более жизнеспособным, с большим временем работы и большей гибкостью для меня, чтобы исправить что-то, когда мой график позволяет, вместо необходимости останавливать все для ремонта сервера.
Надеюсь, я не упустил из виду, что на эти вопросы можно легко найти ответы. Я быстро поискал и не нашел то, что искал.
Во-первых, вам нужно определить, что вы действительно означает "HA". От чего вы защищаетесь, каковы затраты на отключение типа X и длительности Y? Как это повлияет на вашу организацию? Какова ваша роль в этой организации и сколько стоит ваше время? Сколько времени жестяная банка ты тратишь на это? После этого вы должны решить, допускают ли эти требования такое решение или вам нужно что-то еще.
Во-вторых: в моем мире предложения «Мне нужна HA» и «Я собираюсь купить дрянные бывшие в употреблении серверы за 200 долларов» не подходят друг другу (на самом деле, для меня, покупая бывшее в употреблении дерьмо и любое профессиональное использование, это не так. т вообще не подходят друг другу).
Во всяком случае, ваши вопросы:
Если вы записываете совершенно новые данные в блочное устройство DRBD, они будут правильно записаны на исправном контроллере. Это полностью прозрачный слой перед настоящими дисками, как программный RAID или LVM. Однако, если у вас есть повреждение данных на первичном узле из-за неисправных контроллеров или ошибок чтения с диска, это может легко распространиться на вторичный узел, поскольку операции записи часто представляют собой циклы чтения-изменения-записи, и в этом случае блок поврежденные данные будут прочитаны на первичном узле, и операция записи для этого блока будет отправлена на оба узла. Это поднимает самый важный момент при использовании DRBD: Как и RAID, он никоим образом не заменяет хорошую и надежную резервную копию.
Я не понимаю, что вы здесь имеете в виду.
Когда использование виртуальных машин в одном узле полезно, оно также будет в двухузловой настройке, и вы получите преимущество возможной живой миграции, если все будет сделано правильно.
По моему опыту, да. Тем не менее, вы должны тщательно протестировать его в своей среде и потратить много времени на моделирование различных состояний сбоя, которые система может испытать, а также изучить и задокументировать, как их исправить. Несмотря на надежность, DRBD не является самовосстанавливающимся и требует хорошего понимания ситуации для восстановления после сбоя.
Вы действительно требуется выделенное соединение между узлами. В конфигурации с двумя узлами это может быть соединение точка-точка без переключателя или чего-то еще. Все остальное технически возможно, но это чепуха. В зависимости от вашей схемы использования использование транкинговых или более быстрых сетевых адаптеров (например, 10G Ethernet или Infiniband) для этого выделенного канала может быть полезным, но если большая часть / все данные для чтения или записи поступают из интерфейса LAN, это не поможет, поскольку вы все равно ограничены локальной сетью.
Это возвращается к моему первому абзацу: чего вы от этого ожидаете и что вы считаете HA? Для опытного системного администратора это может быть дешевым и надежным способом защиты от целого ряда сбоев, но для этого требуется глубокое понимание того, как части сочетаются друг с другом. Однако многим небольшим магазинам без такого опытного штатного SA лучше иметь качественное оборудование и хороший контракт на поддержку.
Наконец: не пытайтесь задним числом установить какое-либо решение высокой доступности на ваше текущее оборудование. Как я уже писал, ты необходимость время поэкспериментировать с установкой и условиями ее отказа. Это требует большого времени простоя и не может быть разумным на вашем производственном оборудовании.