На моей работе мы используем Linux-бокс для хранения исходного кода и размещения нашего программного обеспечения для контроля версий (svn). У нас также есть некоторые другие продукты, такие как "trac" для управления проектами, fisheye и crustible для проверки кода. Если или когда этот бокс рухнет, я хотел бы иметь возможность поддерживать все службы, программное обеспечение, учетные записи пользователей и т. д. в рабочем состоянии с практически нулевым временем простоя. Какое решение я ищу?
Несколько полезных советов:
- Стоимость решения не имеет значения. Я бы предпочел единовременную оплату, а не подписку.
- Я хочу минимальную административную работу как по поддержанию резервной копии, так и по восстановлению.
- Ящик простаивает ночью и в выходные.
- У нас есть еще одно предприятие в паре миль, но относительно медленное соединение между двумя зданиями (ночью, правда, быстрее). Я бы хотел, чтобы эта опция восстановления была удаленной на случай пожара и т. д.
- Я хочу, чтобы резервная копия была куплена, работала и была готова до того, как я когда-либо к ней обращусь. Не «после сбоя купи новый ящик, ...»
- Ящик не представляет собой ничего особенного, просто стандартный рабочий стол с Ubuntu Linux на нем. Мы не используем его ни для чего, кроме высокой производительности.
Кто-нибудь знает решение для меня? Я не очень разбираюсь в Linux или серверах, поэтому, пожалуйста, дайте базовые пояснения в своих ответах.
Спасибо!
решение1
На самом деле вы говорите о трех взаимосвязанных, но разных вещах:
- Отказоустойчивость (как обеспечить бесперебойную работу или резервное копирование с минимальным временем простоя)
- Резервное копирование данных (что делать, если кто-то использует rm -rf для моего репозитория)
- Восстановление после аварии (Что делать, если мой офис стерт с лица земли)
Вы должны действительно думать о них как о трех отдельных, но взаимосвязанных процессах. Я расскажу больше всего об отказоустойчивости, поскольку это, кажется, то, что вы действительно ищете с максимальным временем простоя в 1 час.
Некоторые моменты, которые следует учитывать для обеспечения отказоустойчивости:
- Сколько времени мне понадобится, чтобы получить новое оборудование?
- Сколько времени мне понадобится, чтобы перестроить коробку?
- Сколько времени мне понадобится на проверку и восстановление данных?
Возьмите сумму этих времен, умножьте на 30% (ничто не всегда проходит так гладко, как вы думаете в чрезвычайной ситуации), и если эта сумма больше, чем ваше приемлемое время простоя, вам нужно начать рассматривать некоторые настройки высокой доступности. Если она меньше, это ваш выбор — пойти на риск, что ваши оценки неверны, и люди могут простаивать дольше, чем вы ожидали.
Что касается возможных решений, то тут много чего можно сделать. Но в каждом случае я бывысокопорекомендуйте заменить настольный компьютер на машину серверного класса. Качество компонентов выше, и они созданы для работы 24x7x365, поэтому в оборудование уже встроена приличная избыточность (хорошие карты RAID, избыточные блоки питания и т. д.)
- Вы можете настроить резервный сервер на втором сайте, а затем rsync ваши данные через каждые x периодов времени - где x - это объем данных, которые вы готовы потерять, если сервер выйдет из строя между репликациями. rsync очень дружелюбен к небольшим каналам данных после первой синхронизации, поскольку он отправляет только дельты и измененные файлы. Также настройте свои серверы так, чтобы они были доступны через CNAME, чтобы вы могли просто поменять местами, куда он указывает, и все готово.
- Сделайте то же самое, что и выше, за исключением того, что резервный сервер должен находиться в вашем основном местоположении.
- Получите SAN/NAS и два сервера. Затем настройте их в кластере Active/Active или кластере Active/Passive.
Резервные копии также являются очень важной частью сценария. Вы должны помнить, что нет замены резервной копии на определенный момент времени, хранящейся вне офиса. Лично я все еще думаю, что резервное копирование на ленту, а затем хранение ее вне офиса компанией вроде Iron Mountain, является наилучшим вариантом. Для среды вашего размера любое из «больших» решений для резервного копирования — ArcServ, BackupExec, NetBackup — должно подойти. Также убедитесь, что вы ТЕСТИРУЕТЕ свои резервные копии по крайней мере раз в квартал. Нет ничего хуже, чем обнаружить, что нужная вам резервная копия плохая.
Восстановление после сбоя на самом деле заключается в том, чтобы просто сесть и спланировать, где вы будете работать, откуда вы получите сменное оборудование, убедиться, что у вас есть хорошие резервные копии за пределами площадки. Я рассматриваю DR как объединение всех компонентов, упомянутых выше, в единый план действий на случай, если произойдет худшее.
решение2
Вы можете виртуализировать среду, и тогда все, что вам нужно будет сделать, это восстановить образ.
решение3
Здесь есть много вариантов в зависимости от объема данных, сложности основной системы и того, какой объем управления вы хотите осуществлять.
Мне нравится XenServer для этого, если виртуализированный ящик относительно небольшого размера (несколько ГБ). Например, внутренний сервер приложений, который мы запускаем, имеет размер всего 3 ГБ. Я могу легко остановить его, сделать резервную копию и перенести ее на другую систему. Однако, если вы не в курсе XenServer, это может быть крутой кривой обучения.
Я также использую программное обеспечение для резервного копирования сервера CDP от R1Soft, но оно не очень подходит для быстрого восстановления. Оно отлично подходит для полного восстановления на «голое железо» отказавшего сервера, но для резервного копирования и восстановления менее чем за час.
Я делал что-то подобное для клиентов: использовал программное обеспечение резервного копирования CDP для клонирования основной системы в холодный резерв. Это гарантирует, что резервная система идентична основной системе. Затем мы храним почасовые снимки на сервере CDP. Сервер CDP использует очень эффективный алгоритм резервного копирования, поэтому на работающий сервер это влияет незначительно.
В случае сбоя вы можете восстановить данные с сервера CDP на «холодный» резерв.
Проблема с этим или подходом на основе rsync заключается в том, что вам нужно быть уверенным в управлении как горячим, так и холодным резервом, чтобы их программное обеспечение оставалось синхронизированным. Вы не захотите запустить обновления ОС на одном и забыть сделать это на другом.
Одна из рекомендаций — постарайтесь как можно лучше использовать стандартизированную конфигурацию на вашем сервере. Это снизит влияние изменений конфигурации/обновлений на восстановление/синхронизацию данных в системе холодного резерва.
Кроме того, мне нравится держать свои данные — то есть то, что я добавляю — хорошо изолированными от системы. Если вы используете LVM, методы моментальных снимков LVM также могут работать.
Существует множество вариантов, но выбор лучшего из них будет зависеть от вашего внутреннего опыта, времени на управление системой и моделей использования данных.
Также, если объем данных очень небольшой, вам, возможно, стоит рассмотреть инструменты резервного копирования/восстановления на уровне настольного компьютера. Я не так хорошо с ними знаком.
http://www.r1soft.com/ Программное обеспечение сервера CDP
http://www.citrix.com/XenServer
решение4
похоже, что здесь может быть достаточно чего-то простого, вроде rsync + cron.