Серверы RHEL6 могут быть “скопированы”?
Моя компания должна установить сервер разработки, и у нас уже есть 2 производства RHEL 6 серверов, работающих под переключателем L4.
Одним из решений установить dev сервер были к простой копии все файлы от одного из рабочих серверов, и настройте его немного.
Я никогда не делал этого прежде, но это звучит подобным для двоения обработки изображений... это может быть сделано? Это рекомендуется? Это было бы подвержено ошибкам?
Копирование всех файлов может сработать. Это будет зависеть от операционной системы и способа копирования.
Одна из общих проблем - это попытка скопировать систему во время ее работы. Обычно, по крайней мере, некоторые файлы будут заблокированы, и поэтому не будут скопированы правильно. Использование какого-то программного обеспечения для создания изображений во время выключения системы обычно наиболее безопасно (вы упомянули Ghost, который является одним из примеров)
.Почему бы не преобразовать запущенные системы в виртуальные машины? Большинство гипервизоров, таких как VMware или Hyper-V, имеют инструмент, позволяющий легко преобразовать запущенную систему в виртуальную машину.
Затем вы можете работать с непроизводственной системой, как вам угодно, прежде чем делать что-либо на производственном сервере.
Благодаря @WernerCD
Можно ли это сделать?
Определенно да. Я скопировал весь Linux-сервер, просто упаковали файлы с tar и снова извлекли их на целевом сервере. Единственным предостережением, которое я помню, было использование --numeric-owner при извлечении. Я не могу говорить за другие операционные системы и другие инструменты, но думаю, что это можно сделать со всеми основными операционными системами.
Должно ли это быть сделано?
На этот вопрос ответить немного сложнее. Я не буду рекомендовать просто клонирование производственной системы с целью разработки. Вполне возможно, что она будет содержать большое количество пользовательских данных, а также ключевой материал, который вы не захотите иметь на системах разработки.
Но клонирование вашей производственной системы может быть хорошей идеей и для других целей.
Подход, который я бы рекомендовал для создания клона производственной системы, заключается в восстановлении из резервной копии. Вы можете избежать влияния производительности на производственную систему, восстанавливая из резервной копии, и вы сможете протестировать процедуру восстановления, что хорошо.
Очень важно держать клон, который вы восстановили из резервной копии, изолированным от остального мира. Поскольку он был восстановлен из резервной копии производственной системы, он может содержать автоматизированные задания, которые будут взаимодействовать с другими производственными системами, и у него будут на это полномочия.
Потенциально вы можете нанести большой ущерб, если клон будет взаимодействовать с реальными производственными системами.
Но если вы будете держать его изолированным, это даст вам возможность протестировать, что восстановленная система работает так, как вы задумывали.
Вы сможете протестировать, что клон, который вы восстановили, работает так, как вы задумывали. Более того, такая восстановленная система может быть полезной средой для последнего тестирования нового кода перед его развертыванием в промышленном масштабе. Это может быть ваша единственная возможность протестировать код на реальных пользовательских данных, прежде чем он действительно сможет сломать производственную систему.
.Возможность
Конечно, это возможно, потому что нетрудно "установить" Linux, используя нетрадиционные средства. Вы можете, например, реплицировать сервер, используя rsync по SSH.
- Загрузить целевую машину в "спасательный" образ, используя Red Hat DVD, живую загрузку Ubuntu, Knoppix, что угодно.
- Разделите и отформатируйте целевую машину, и смонтируйте файловые системы по
/target. - rsync всех соответствующих файловых систем по SSH (пропустите
/proc,/sys, подкачайте). - Исправьте
/target/etc/fstab, особенно если на разделы ссылаются по UUID. - Подкорректируйте имя хоста и сетевую конфигурацию соответствующим образом.
- Установите системный загрузчик.
Шаг 3 может состоять из нескольких rsync-пассов, возможно, с помощью LVM снимков на исходной машине, последний проход со всеми сервисами на исходной машине остановлен для обеспечения согласованности данных.
Желательность и лучший опыт
То, что вы не можете, не означает, что вы должны это делать. Я рекомендовал вышеприведенный процесс в качестве одного из способов миграции центра данных. Однако, ваш вариант использования совершенно другой. Обращение к клонированию подчеркивает некоторые недостатки:
- Виртуализация была бы хорошей возможностью и сделала бы репликацию легкой.
- Есть ли у вас резервные копии вашего производственного сервера (серверов)? Почему бы просто не восстановить их? Это было бы хорошей проверкой вашей процедуры восстановления резервных копий.
- Есть ли у вас документация о том, как воссоздать все с нуля? В конце концов, вам, вероятно, понадобится установить все с нуля, возможно, при обновлении операционной системы. Это было бы хорошей проверкой вашей документации.
- А еще лучше, есть ли у вас автоматизация, которая поможет вам воспроизвести вашу установку? Скрипт оболочки может сработать; решение по управлению конфигурацией, такое как CFengine, Puppet, Chef или Ansible, было бы еще лучше.
Если вы слепо клонируете рабочий сервер, вы потеряете ценную возможность уточнить, что именно на нем выполняется.
.