*nix CARP или VMWare Отказоустойчивость?
Мы экспериментируем с тем, что VMWare называет "полностью разрушенной DMZ" в центре лезвия. По сути, наша DMZ переходит прямо в vSwitch, и все устройства безопасности виртуализированы.
Я провел дни, читая о том, почему это хорошая идея и почему это плохая идея, что нужно сделать, чтобы сделать ее безопасной, и т. Д., Но единственное, что мне не удается найти, - это информация о лучшей отказоустойчивости метод.
Нашим предпочтительным межсетевым экраном является pfSense, который поддерживает CARP. У нас есть 10 блэйдов в кластере, поэтому вполне возможно иметь два или даже три брандмауэра pfSense с включенной VMWare HA и сконфигурированными внутри с помощью CARP, которые в случае сбоя блейд-сервера будут захватывать друг друга. Но это похоже на большие административные издержки, и я не доверяю, так что это означает, что я буду входить в несколько брандмауэров каждую неделю, чтобы убедиться, что все наши правила и т. Д. Отражены.
Но зачем беспокоиться о CARP, когда FT от VMWare (даже с одним дефицитом vCPU) обеспечит все функции CARP и, насколько я могу судить, меньше менеджмента, стресса и беспокойства о моей работе.
ТЛ; др:
Есть ли веская причина использовать CARP поверх FT или наоборот для программного брандмауэра?
3 ответа
Хотя я играл с FT целую вечность, честно говоря, я пока не нашел реального применения. Мало того, что одиночный vCPU - это боль, но и объем генерируемого сетевого трафика удивителен. Вы действительно в конечном итоге используете большую часть GigE-ссылки только для FT, поэтому вы в конечном итоге перебрасываете свой трафик vMotion через другой vswitch, что делает его довольно неприятным, если честно. Моя другая проблема заключается в том, что FT защищает вас только от физических сбоев. Если виртуальная машина FT по какой-либо причине перестанет работать, вы все равно потеряете сервис, поскольку сбой будет отлично отражаться на вторичной виртуальной машине.
Я осторожный парень, когда дело доходит до производственных систем, и я просто не думаю, что FT стоит того, надеюсь, что это изменится, но вместо этого у меня появятся другие системы, такие как кластеризация /VIP и т. Д.
Да, и не беспокойтесь о разрушенных демилитаризованных зонах, если вы используете один из продуктов vShield, я лично считаю, что они так же безопасны, как и любая коробка Cisco.
CARP действительно разработан, чтобы позволить вашим хостам определять, находится ли сетевой адаптер другого хоста в автономном режиме (что часто бывает, когда физический хост выключен, но не обязательно)
Преимущество использования CARP по сравнению с VMWare FT будет в том случае, если VMWare FT будет вести себя по-разному в случае сбоя сетевого адаптера.
Если вам удобно работать с брандмауэром на виртуальной машине, единственное, что меня беспокоит, - это поведение FT при сбое сетевой платы. Если сбой NIC не приводит к аварийному переключению FT, то я бы оставил за собой CARP.
В дополнение к тому, что упомянул Крис С., с которым я согласен, я бы также пошел с CARP, потому что, что происходит, когда вы обновляете брандмауэр или выполняете какие-либо другие виды обслуживания, требующие перезагрузки или выключения? С FT вы не работаете, пока он перезагружается, с CARP он полностью прозрачен. Или, если вам нужно что-то изменить на виртуальной машине, чего нельзя сделать, пока она активна, вы должны отключить все. Используйте CARP, и вы будете в хорошей форме во всех этих сценариях. FT в основном предназначен для защиты от аппаратных сбоев, где CARP удовлетворяет любые мыслимые потребности в обслуживании без простоев, а также обеспечивает защиту от аппаратных сбоев.