Назад | Перейти на главную страницу

Горячее клонирование живого Linux-сервиса

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

У нас есть вычислительный узел, можно сказать, вычислительный узел НЛП, который запускает на нем некоторые модели. Когда мы запускаем узел (конечно, с сервисом), вычисления будут ужасно медленными, пока мы не будем кормить его несколько раз. Мы назвали это разминкой.

К сожалению, работа на разогрев занимает много времени (возможно, наши вычисления закончились до того, как узел нагрелся).

Итак, возникает проблема: есть ли стабильный способ горячего клонирования сервера Linux для поддержания максимальной производительности узла, чтобы мы могли клонировать и перевести его в оперативный режим в более короткие сроки?

Возможно, вы не можете выполнить «горячее клонирование» всего сервера (вы можете, но только если это виртуальная машина), но вы можете заморозить и восстановить один процесс с помощью криу, Контрольная точка / восстановление в пользовательском пространстве.

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

Для поддержки желаемой операции вы можете скопировать файлы, представляющие сохраненную программу, на другой сервер и восстановить ее там.

Для criu требуется последнее ядро ​​с различными встроенными функциями, поэтому старые дистрибутивы Linux могут не работать. Вы можете запустить criu check на конкретной машине, чтобы определить, имеются ли предпосылки для криу.

Это может быть немного за пределами вашей текущей среды, но стандартный способ сделать это - виртуализировать ваш сервер. Многие хосты виртуализации (VMware, virtualbox и т. Д.) Позволяют создавать «моментальные снимки», сохраняющие состояние сервера, которые затем можно клонировать в новые экземпляры. Эти новые экземпляры будут иметь точно такое же состояние, что и исходные, вплоть до запущенных процессов. Конечно, вы захотите убедиться, что программное обеспечение, которое вы используете, по-прежнему будет правильно работать в виртуальной среде (на ум приходят вычисления CUDA / GPU).

Указанный вами вопрос относится к ссылке, http://www.linuxfocus.org/English/March2005/article370.shtml, которые описывают все способы, которые я придумал для выполнения ваших запросов.

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

Не совсем понятно, что вы имели в виду под «пока не накормим несколько раз».

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

Чтобы выполнить «ВКЛ / ВЫКЛ» или, лучше сказать, активную / резервную среду, сервер должен быть правильно настроен в кластере.

Прошу прощения, если это не тот ответ, на который вы рассчитываете, но вы получите следующие варианты.

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

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

Во-первых, чтобы определить лучшую стратегию обработки данных, было бы полезно знать, что регулярно обновляется. У вас есть сервер SQL, который динамически обновляется, но имеет статический контент? В качестве альтернативы, есть ли у вас команда разработчиков над системой подрывной деятельности, такой как git, которая постоянно обновляет данные для вашего контента? В зависимости от того, что обновляется, будет определяться наиболее полный курс действий.

Если, например, регулярно обновляется только SQL, то вы можете перейти на новый сервер, пока этот сервер работает, следующим образом:

  • dd клонировать все данные на новый сервер.
  • Начните настройку нового сервера, это может потребовать некоторой работы, особенно если это другое оборудование, но все же может быть быстрее, чем настройка с нуля.
  • Это также может потребовать некоторых изменений DNS, поскольку вы не можете использовать тот же DNS на другом сервере, если вам нужно работать на втором сервере в реальном времени, пока первый сервер все еще работает.
  • После того, как новый сервер будет готов и работает независимо, сделайте последнюю резервную копию sql-сервера на исходном сервере и импортируйте ее на новый сервер.

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

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

Другая проблема связана с аппаратной конфигурацией сервера. Аппаратно ли новый сервер на 100% идентичен старому? Если да, то настройка проще. Однако, если, с другой стороны, это совершенно другая конфигурация оборудования, тогда вам может потребоваться реализовать другую стратегию, которая заключается в простой настройке второго сервера заранее, а затем резервном копировании всех ваших данных и баз данных sql на первый сервер и вручную перенести их, изменив конфигурацию по желанию.

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

Надеюсь, это поможет, и удачи в перемещении вашего сервера!