Добрый день, я новичок в FreeNAS, нужна помощь в решении задачи - есть два сервера с поднятым FreeNAS, один рабочий (файловое хранилище и виртуалка), второй резервный. На втором должна быть копия ВСЕХ данных первого включая виртуалку. На случай выхода из строя первого, пользователи должны начать пользоваться вторым. Заранее спасибо за помощь. Куда рыть.
-
Important Announcement for The TrueNAS Community.
The TrueNAS Community has now been moved. This forum will now become READ-ONLY for historical purposes. Please feel free to join us on the new TrueNAS Community Forums
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Вопрос
- Thread starter Alex_2019
- Start date
Определитесь с требованиями.
Вам нужно, что бы "никто ничего не заметил"? Тогда это HA, высокая доступность, и, скорее всего, Вам надо будет покупать TrueNAS.
А если Вы допускаете простой, то сколько - 1 минуту, 1 час, 1 день? И что за виртуалка?
Вы можете настроить копирование данных с основного сервера на резервный. Но длительность копирования и интервал запуска копирования ограничивают Вас в доступности и "свежести" данных на резервном сервере для пользователей.
Вам нужно, что бы "никто ничего не заметил"? Тогда это HA, высокая доступность, и, скорее всего, Вам надо будет покупать TrueNAS.
А если Вы допускаете простой, то сколько - 1 минуту, 1 час, 1 день? И что за виртуалка?
Вы можете настроить копирование данных с основного сервера на резервный. Но длительность копирования и интервал запуска копирования ограничивают Вас в доступности и "свежести" данных на резервном сервере для пользователей.
Тогда все очень просто. Настраиваете синхронизацию между серверами удобным для вас способом 2 раза в сутки.
В документации к FreeNAS есть раздел
7.3. Rsync Tasks
Если Ваше файловое хранилище предоставляется Windows клиентам, то можно, имея доступ к обоим серверам с Windows машины настроить синхронизацию с нее - например, robocopy.
С копированием вашей виртуальной машины с Linux сложнее, но тоже решается соответствующими инструментами. Будет зависеть от задач, настроенных в ней и данных, хранящихся там. Виртуалка может быть настроена одинаково на обоих серверах, а вам будет нужно только копировать данные из основной на резервный экземпляр.
В документации к FreeNAS есть раздел
7.3. Rsync Tasks
Если Ваше файловое хранилище предоставляется Windows клиентам, то можно, имея доступ к обоим серверам с Windows машины настроить синхронизацию с нее - например, robocopy.
С копированием вашей виртуальной машины с Linux сложнее, но тоже решается соответствующими инструментами. Будет зависеть от задач, настроенных в ней и данных, хранящихся там. Виртуалка может быть настроена одинаково на обоих серверах, а вам будет нужно только копировать данные из основной на резервный экземпляр.
Остается вопрос переподключения пользователей от основного к резервному серверу, но это сильно зависит от типа подключения.
Можно просто поменять IP адрес резервного на IP адрес основного.
А как с правами доступа к ресурсам основного и резервного файлового хранилища? Эти права доступа должны совпадать. Не зная, как у вас это все настроено, давать рекомендации бесполезно.
Можно просто поменять IP адрес резервного на IP адрес основного.
А как с правами доступа к ресурсам основного и резервного файлового хранилища? Эти права доступа должны совпадать. Не зная, как у вас это все настроено, давать рекомендации бесполезно.
Для полной репликации со всеми правами и снапшотами, а за одно и эффективного выделения изменений, лучше вместо rsync использовать встроенную в ZFS и FreeNAS репликацию. При желании ее можно хоть каждый час делать. Можно и каждые 5 минут, бывают такие люди, но такое число снапшотов сложно в управлении. Переключение на разерв и разворот репликации прийдется правда делать вручную, но тут уж ничего не поделаешь пока.
При репликация создается точная копия соответствующих ZFS dataset/zvol. Перенос всего что поверх этого работало -- задача администратора. Как частный вариант, если сервера в меру идентичные и имеется свеже сохраненная конфигурация первого, а второй своих сервисов и настроек не имел, только данные, то конфигурацию первого можно просто залить на второй, примонтировать пул с реплицированными данными и пустить в работу под видом первого. Конечно при этом когда первых оживет надо будет его пененастраивать в новый бакап.
Сервера полностью идентичны, второй будет являться только резервным и до момента выхода из строя первого использоваться не будет. После того как на второй сервер залить конфигурацию первого и примонтировать пул с реплицированными данными, это будет точная копия со всеми данными и виртуальными машинами первого, правильно ?
Всё таки не пойму, к чему такие сложности ?
Во первых - имеем идентичное оборудование - т.е. в случае выхода из строя материнской платы или рейд-контроллера - можем переставить их.
Во вторых - сбои дисков компенсируются самой ZFS - RAIDZ2 например.
Какой смысл жечь электричество вторым сервером ? И диски с него можно использовать в первом для организации более защищённого массива.
Единственный смысл, если память стоит не ECC и есть риски, что испортятся данные. Ну или сервер сгорит полностью, вместе с дисками.
В общем, IMHO, лучше собрать второй сервер - и его выключить, в случае чего просто перенести диски из первого сервера во второй и включить.
Конечно - бэкапы никто не отменял. Но можно бэкапировать только критичные (или просто) данные.
Во первых - имеем идентичное оборудование - т.е. в случае выхода из строя материнской платы или рейд-контроллера - можем переставить их.
Во вторых - сбои дисков компенсируются самой ZFS - RAIDZ2 например.
Какой смысл жечь электричество вторым сервером ? И диски с него можно использовать в первом для организации более защищённого массива.
Единственный смысл, если память стоит не ECC и есть риски, что испортятся данные. Ну или сервер сгорит полностью, вместе с дисками.
В общем, IMHO, лучше собрать второй сервер - и его выключить, в случае чего просто перенести диски из первого сервера во второй и включить.
Конечно - бэкапы никто не отменял. Но можно бэкапировать только критичные (или просто) данные.
Всё таки не пойму, к чему такие сложности ?
Ваше удивление понятно, если Вы готовы потратить от нескольких часов до нескольких дней на восстановление работоспособности. Можно назвать такое решение - холодный резерв.
Есть подход - горячий резерв. Резервный сервер включен, на нем относительно актуальные данные. Переключение на него займет от нескольких нескольких секунд до десятков минут в зависимости от конфигурации сети и настроек и расторопности админа.
Выбор за админом с ориентиром на поставленную задачу - за минимальные деньги - минимальный простой бизнеса. Но в разных организациях минимальное время простоя и суммы, выделяемые на это - разные.
Какие дни ? Переткнуть диски из одного корпуса в другой - дни ?если Вы готовы потратить от нескольких часов до нескольких дней на восстановление работоспособности.
на нем относительно актуальные данные. Переключение на него займет от нескольких нескольких секунд до десятков минут в зависимости от конфигурации сети и настроек и расторопности админа.
Всё о чём мы спорим - это управление рисками. Если простой критичен - то HA самое лучшее решение.
Всё о чём мы спорим - это управление рисками. Если простой критичен - то HA самое лучшее решение.
А мы с Вами и не спорим. Вначале Вы привели пример, когда простой не страшен - занимайся целый день, сотрудники подождут. Теперь Вы привели пример HA, это другая крайность, дорогая и обоснованная в случае очень серьезного бизнеса. А есть решение посередине, о нем я и говорил. И ТС имеет ввиду именно это решение - горячий резерв.
У меня в практике было два случая, когда серверную заливало водой. (Не мою серверную) Уже страшно? Или по-проще - вышли из строя два диска в зеркале.Какие дни ? Переткнуть диски из одного корпуса в другой - дни ?
Вот это те ситуации, когда перетыканием дисков ничего не решишь, и потребуется время на замену железа.
И тут я с Вами согласен - это управление рисками.
Если Вы создадите такую же виртуальную машину на резервном сервере, то возможно, Вам можно будет переносить только данные с основной на резервную копию.
Вы не указали, что за виртуалка. Какие функции - сервисы она обеспечивает? От этого будет зависеть план репликации. Вся виртуалка, или только данные, которые она использует?
И как она взаимодействует с сетью - какой IP, DNS имя, доступ к ней из локалки или из интернета? Вам надо это все спланировать и определить, как Вы будете переходить на резервный сервер в случае катастрофического отказа.
Просто представьте, что основной сервер недоступен, но есть резервный, с почти актуальными (копия была сделана 6 часов назад) данными. Как к нему получить доступ сотрудникам? У него другие IP, DNS имя, smb шара.
Вы не указали, что за виртуалка. Какие функции - сервисы она обеспечивает? От этого будет зависеть план репликации. Вся виртуалка, или только данные, которые она использует?
И как она взаимодействует с сетью - какой IP, DNS имя, доступ к ней из локалки или из интернета? Вам надо это все спланировать и определить, как Вы будете переходить на резервный сервер в случае катастрофического отказа.
Просто представьте, что основной сервер недоступен, но есть резервный, с почти актуальными (копия была сделана 6 часов назад) данными. Как к нему получить доступ сотрудникам? У него другие IP, DNS имя, smb шара.
Я так понимаю, что для обеспечения минимального времени простоя правильнее делать репликацию, а как быть с виртуальной машиной которая поднята на насе?
Диски виртуальной машины хранятся на пуле как ZVOL'ы и тоже могут быть реплицированы, а ее конфигурация является частью конфигурации FreeNAS и ее хорошо бы нужно регулярно сохранять и можно импортировать. К сожалению экспорта/импорта отдельной VM вроде пока нет (не уверен), что пожалуй упущение и заслуживает тикета.