IPSec использует CISCO EasyVPN, а вот SSL VPN (clientless и client oriented) использует в качестве протокола передачи именно SSL. Вся идея в том, что используя SSL, мы сможет осуществить удаленное подключение с вероятность 99% (SSL открыт практически везде). А вот с использованием IPSec могут быть проблемы. Тут стоит отметить не только фильтрацию фаерволом, но и возможные проблемы с MTU.
Использование clientless SSL VPN предоставляет большую гибкость: возможность подключиться к корпоративным ресурсам и/или ресурсам Интернет используя корпоративный портал + шифрование. Доступно с любого устройства с браузером.
Конечно такой параметр есть, но до него еще дойти нужно. В своей практике практически с ним не сталкивался. А как этот параметр поможет в данных ситуациях?
Основная идея в том, что не так уж мало зависит от Ваших upstream'ов и от их peer'ов и/или upstream'ов.
Если Вы устанавливаете в 7600/6500 шасси такие модули как SIP/SPA/ES/ES+ (то есть WAN карточки), то по сути в модульный коммутатор Вы устанавливаете ОТДЕЛЬНЫЙ маршрутизатор выполненный в форм факторе модуля (блейда).
Это все хорошо, но на текущий момент скорее баловство для вендоров и инженеров. Даже 40G на текущий момент выглядят на порядок не привлекательнее 4*10G. Цены и наличие оборудования не радуют.
Сюда следует добавить поведение в реальных условиях. 10G на огромный порядок капризнее 1G и более требовательны в качеству линии (из личного опыта расскажу, что был случай, когда 1.2 км расстояния просвети только 40-ка километровым модулем. Вот Вам и затухания. Отдельное спасибо сварщикам оптики). С 40G проблем будет еще больше.
Вы не поняли смысла. То что модули работает, ни как не связано с тем, что производитель рекомендует и продает. Вы думаете что любой вендор склепал модуль и сразу на рынок?
Оптимизм заканчивается, когда установленный сторонний модуль начинает выпадать в error-disable, на нем появляются ошибки/потери, интерфейс начинает «флапать», происходит рассогласование скоростей и дуплекса и т.д. Это все не выдумки, а случаи из личного опыта.
После этого такая сомнительная экономия превращается в полноценный геморрой.
Вы не найдете ни одного вендора, который заявит о том, что в его железе можно использовать любые оптические модули (сторонних производителей). То что модули работают — это совсем другое дело.
Прежде чем выпустить модуль, производитель проводит не одно тестирование на корректность работы и совместимость. Пользуемся железом CISCO и только ихними модулями — за все время проблем не было. Работает как часы.
Если у вас проект на сотни тысяч денег, то экономить пару сотен долларов на оптических модулях по крайней мере глупо.
Ну и L2 DCI (безусловное требование для любых видов VM mobility) — нечто, от чего лучше держаться подальше, если только в нем нет абсолютной необходимости (а обычно ее нет). Не очень здорово даже когда один VLAN растянут на целый ЦОД.
Тем не менее, такой тренд есть. И судя по тому, сколько усилий в этот направлении тратят производители сетевого оборудования и платформ виртуализации, функционал востребован заказчиками.
Касательно Live Migration между ЦОД.
Если клиент задумывает о миграции между ЦОД, то однозначно у него будет некая кластеризированная СХД с полностью реплицированной информацией. Иначе нет смысла мигрировать в другой ЦОД при Disaster Recovery. Если мигрировать в другой ЦОД для выполнения там вычислительных операций, а хранилище иметь в начальном ЦОДе, то вариант возможен, но очень глупый. Исходя из этого, в другой ЦОД необходимо будет перетянуть только состояние оперативной памяти, диски там уже будут, причем в максимально актуальном состоянии.
Дело не в том, что я хочу узнать как создавать приватное облако. Сам работают в не маленькой организации, которая достаточно давно и очень обширно использует облачную архитектуру.
Суть в том, что интересно было бы узнать о тех решениях, которые Вы внедрили для удовлетворения потребностей в конкретном случае.
Просто заголовок достаточно громкий, а информация об облаке — «вокруг да около». Если бы убрать пару абзацев (well-known) об облаке, то никто бы и не заметил.
Анализируя список, так и хочется сказать: «Из 11 параметров Вы можете выбрать любые 8».
Практически все реализуемо с помощью прокси сервера Squid с обвязками (Rejik+SAMS+AD, можно даже антивирус добавить и еще что-то). Для шейпинга — pf с очередями.
В вашем списке режет глаз Netflow. Как-то это требование не вяжется со всеми остальными. Скажу так, более-менее нормальных реализаций бесплатных Netflow коллекторов под *nix я не встречал. Есть крутые — но очень платные, или «как-бы» бесплатные. Зачем вам вообще в этой реализации Netflow?
Использование clientless SSL VPN предоставляет большую гибкость: возможность подключиться к корпоративным ресурсам и/или ресурсам Интернет используя корпоративный портал + шифрование. Доступно с любого устройства с браузером.
Пример:
ip route 192.168.100.1 255.255.255.255 Null0
ip access-list standard bad-hosts
permit 1.1.1.1 0.0.0.0
permit 2.2.2.2 0.0.0.0
route-map NULL-ROUTE permit 5
match ip address bad-hosts
set ip next-hop 192.168.100.1
interface Gix/x
ip policy route-map NULL-ROUTE
Будете просто в ACL bad-hosts дописывать адреса «вражеских» хостов.
Основная идея в том, что не так уж мало зависит от Ваших upstream'ов и от их peer'ов и/или upstream'ов.
Сюда следует добавить поведение в реальных условиях. 10G на огромный порядок капризнее 1G и более требовательны в качеству линии (из личного опыта расскажу, что был случай, когда 1.2 км расстояния просвети только 40-ка километровым модулем. Вот Вам и затухания. Отдельное спасибо сварщикам оптики). С 40G проблем будет еще больше.
Оптимизм заканчивается, когда установленный сторонний модуль начинает выпадать в error-disable, на нем появляются ошибки/потери, интерфейс начинает «флапать», происходит рассогласование скоростей и дуплекса и т.д. Это все не выдумки, а случаи из личного опыта.
После этого такая сомнительная экономия превращается в полноценный геморрой.
Прежде чем выпустить модуль, производитель проводит не одно тестирование на корректность работы и совместимость. Пользуемся железом CISCO и только ихними модулями — за все время проблем не было. Работает как часы.
Если у вас проект на сотни тысяч денег, то экономить пару сотен долларов на оптических модулях по крайней мере глупо.
Тем не менее, такой тренд есть. И судя по тому, сколько усилий в этот направлении тратят производители сетевого оборудования и платформ виртуализации, функционал востребован заказчиками.
Касательно Live Migration между ЦОД.
Если клиент задумывает о миграции между ЦОД, то однозначно у него будет некая кластеризированная СХД с полностью реплицированной информацией. Иначе нет смысла мигрировать в другой ЦОД при Disaster Recovery. Если мигрировать в другой ЦОД для выполнения там вычислительных операций, а хранилище иметь в начальном ЦОДе, то вариант возможен, но очень глупый. Исходя из этого, в другой ЦОД необходимо будет перетянуть только состояние оперативной памяти, диски там уже будут, причем в максимально актуальном состоянии.
Суть в том, что интересно было бы узнать о тех решениях, которые Вы внедрили для удовлетворения потребностей в конкретном случае.
Практически все реализуемо с помощью прокси сервера Squid с обвязками (Rejik+SAMS+AD, можно даже антивирус добавить и еще что-то). Для шейпинга — pf с очередями.
В вашем списке режет глаз Netflow. Как-то это требование не вяжется со всеми остальными. Скажу так, более-менее нормальных реализаций бесплатных Netflow коллекторов под *nix я не встречал. Есть крутые — но очень платные, или «как-бы» бесплатные. Зачем вам вообще в этой реализации Netflow?