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

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

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

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

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

14
задан 31 January 2019 в 15:48
4 ответа

Возможно, Вы не можете "горячий клон" целый сервер (Вы можете, но только если это - виртуальная машина), но можно заморозить и восстановить единственный процесс, с criu, Контрольная точка/Восстановление в Пространстве пользователя.

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

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

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

28
ответ дан 20 November 2019 в 23:01

Это может быть немного вне объема Вашей текущей среды, но промышленный стандарт способ сделать это должен виртуализировать Ваш сервер. Много хостов виртуализации (VMware, virtualbox, и т.д.) позволяют “snapshots”, которые сохраняют состояние сервера, который может затем быть клонирован в новые экземпляры. Эти новые экземпляры будут иметь точно то же состояние как оригинал, вниз к выполнению процессов. Конечно, you’ll хотят удостовериться, что программное обеспечение, которое выполнение you’re все еще выполнит правильно в виртуальной среде (CUDA/вычисление GPU приходит на ум).

12
ответ дан 20 November 2019 в 23:01

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

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

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

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

Для выполнения "НА/" или лучше названный активной/резервной средой сервер должен быть правильно настроен в кластере.

я сожалею, если не будет ответ, то Вы ожидаете, но опции, которые Вы получаете, являются этим.

3
ответ дан 20 November 2019 в 23:01

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

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

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

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

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

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

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

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

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

Hope это помогает, и удача с Вашим перемещением сервера!

1
ответ дан 20 November 2019 в 23:01

Теги

Похожие вопросы