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

Как настроить Linux-бокс для легкого восстановления?

В моей работе мы используем Linux-бокс для хранения исходного кода и размещения нашего программного обеспечения для контроля версий (svn). У нас также есть некоторые другие продукты, такие как «trac» для управления проектами, «рыбий глаз» и «Crucible» для проверки кода. Если или когда эта коробка перевернется, я хотел бы иметь возможность поддерживать все службы, программное обеспечение, учетные записи пользователей и т. Д. В рабочем состоянии с почти нулевым временем простоя. Какое решение я ищу?

Несколько полезных советов:
- Стоимость решения не является проблемой. Я бы предпочел одноразовую оплату, чем подписку.
- Я хочу минимальную работу администратора как для поддержки резервного копирования, так и для восстановления.
- Коробка простаивает ночью и в выходные.
- У нас есть еще один объект в паре миль отсюда, но связь между двумя зданиями относительно медленная (хотя ночью быстрее). Я бы хотел, чтобы этот вариант восстановления был удален на случай пожара и т. Д.
- Я хочу, чтобы резервная копия была куплена, запущена и готова, прежде чем я когда-либо к ней обращусь. Не «после аварии купите новую коробку, ...»
- Коробка ничего особенного, просто стандартный рабочий стол с Ubuntu linux на нем. Мы не используем его для высокой производительности.

Кто-нибудь знает решение для меня? Я плохо разбираюсь в чем-либо, что связано с Linux или сервером, поэтому, пожалуйста, дайте базовые объяснения своим ответам.

Спасибо!

Фактически вы говорите о трех взаимосвязанных, но разных вещах:

  1. Отказоустойчивость (как мне продолжить работу или получить резервную копию с минимальным временем простоя)
  2. Резервное копирование данных (что мне делать, если кто-то rm -rf выберет мой репозиторий)
  3. Аварийное восстановление (что мне делать, если мой офис стерли с лица земли)

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

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

  • Сколько времени у меня уйдет на получение нового оборудования?
  • Сколько времени у меня уйдет, чтобы восстановить коробку?
  • Сколько времени у меня уйдет на проверку и восстановление данных?

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

Что касается некоторых возможных решений, вы можете многое сделать. Но в любом случае я бы очень рекомендую заменить рабочий стол машиной серверного класса. Качество компонентов выше, и они созданы для работы в режиме 24x7x365, поэтому в оборудование уже встроено приличное количество резервов (хорошие карты RAID, избыточные блоки питания и т. Д.)

  • Вы можете настроить резервный сервер на своем втором сайте, а затем выполнять синхронизацию данных через каждые x промежутков времени, где x - это объем данных, который вы готовы потерять, если сервер выйдет из строя между репликациями. rsync - это очень маленький канал данных, удобный после первой синхронизации, поскольку он отправляет только дельта-файлы и измененные файлы. Также настройте свои серверы так, чтобы к ним можно было получить доступ через CNAME, чтобы вы могли просто поменять местами, где они указаны, и вперед.
  • Сделайте то же, что и выше, за исключением того, что резервный сервер должен находиться в вашем основном месте.
  • Получите SAN / NAS и два сервера. Затем настройте их в активный / активный кластер или активный / пассивный кластер.

Резервные копии также являются очень важной частью сценария. Вы должны помнить, что нет замены для резервной копии на определенный момент времени, хранящейся за пределами площадки. Лично я по-прежнему считаю, что резервное копирование на магнитную ленту, а затем хранение этой информации за пределами предприятия такой компанией, как Iron Mountain, является лучшим вариантом. Для среды вашего размера подойдет любое из «больших» решений для резервного копирования - ArcServ, BackupExec, NetBackup. Также не реже одного раза в квартал проверяйте свои резервные копии. Нет ничего хуже, чем узнать, что резервная копия вам нужна.

Аварийное восстановление на самом деле - это просто сесть и спланировать, где вы будете работать, откуда вы получите оборудование на замену, и убедитесь, что у вас есть хорошие резервные копии вне офиса. Я рассматриваю DR как объединение всех упомянутых выше компонентов в единый план действий на случай худшего.

Здесь есть много вариантов в зависимости от объема данных, сложности основной системы и того, сколько управления вы хотите сделать.

Мне нравится XenServer за это, если виртуализированный ящик относительно невелик по размеру (несколько ГБ). Например, размер внутреннего сервера приложений, который мы запускаем, составляет всего 3 ГБ. Я могу легко остановить его, сделать резервную копию и перенести резервную копию в другую систему. Однако, если вы не в совершенстве владеете XenServer, это может быть сложной кривой обучения.

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

Я сделал что-то подобное для клиентов: используйте программное обеспечение резервного копирования CDP, чтобы клонировать основную систему в холодный резерв. Это гарантирует, что резервная система идентична основной системе. Затем у нас есть ежечасные снимки, хранящиеся на сервере CDP. Сервер CDP использует очень эффективный алгоритм резервного копирования, поэтому он практически не влияет на работающий сервер.

В случае сбоя вы можете восстановить данные с сервера CDP в свой холодный резерв.

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

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

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

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

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

http://www.r1soft.com/ Программное обеспечение сервера CDP

http://www.citrix.com/ XenServer

http://samba.anu.edu.au/rsync/ rsync

Вы можете виртуализировать среду, тогда все, что вам нужно сделать, это восстановить образ.

Не запускайте производственное программное обеспечение на настольном оборудовании. По крайней мере, поместите 2 диска в коробку и настройте для них программный рейд, но это неоптимально в случае сбоя диска: вам все равно придется выключить сервер, чтобы заменить диск. С серверным оборудованием у вас не будет такой проблемы: горячая замена.

Следите за состоянием оборудования (много бесплатных инструментов мониторинга, я бы выбрал opsview, потому что это nagios с великолепным веб-интерфейсом. Вы по-прежнему получаете все плагины nagios для работы в нем). У них также есть корпоративная версия для всей необходимой поддержки.

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

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

Я согласен с Игнасио Васкес-Абраном в том, что программное обеспечение для управления конфигурацией, в конце концов, является самым важным. Я бы выбрал cfengine, но puppet - это ресурсная свинья, и она более разрекламирована, чем должна быть. Если вам нужен еще один svn-сервер, просто загрузите его по сети, он сам будет установлен и настроен за считанные минуты. Вы также можете купить у них всю необходимую поддержку.

Кажется, здесь может быть достаточно чего-то столь же простого, как rsync + cron.

Кукольный может использоваться для запуска и запуска системы, когда она вам понадобится. Установите минимальную установку, добавьте клиент Puppet и позвольте Puppetmaster выполнить свою работу по настройке машины.