Comments 8
Скажите, а что вы используете в качестве финального софтового свитча на хостах? Open vSwitch? Или brtools?
Это в основном определяется тем, что поддерживает тот или иной релиз платформы OpenStack. Для более старых релизов (2012.1) единственным вариантом при установке на Linux было использование нативных бриджей, управляемых через brtools. В новых версиях платформы, начиная с 2012.2, основным сервисом управления сетью стал Quantum, который поддерживает как brtools, так и OpenVSwitch. В различных наших проектах мы использовали как нативные бриджи, так и Quantum+OVS.
Скажите, а что вы делаете с проблемой нестабильности обоих решений? Для понимания вопроса: 15 мегабит специально подготовленного трафика положит ваш хост вне зависимости от мнения о происходящем iptables, open flow контроллера и т.д.
В случае с brtools ситуация чуть лучше, но что вы делаете после получения 100kpps и 800% irq?
В случае с brtools ситуация чуть лучше, но что вы делаете после получения 100kpps и 800% irq?
Описанные в статье практики не имеют целью защиту от DoS-атак, только высокую доступность сервисов. Для обеспечения подобной защиты необходимо применять сторонние IDS решения.
Но вы же понимаете, что я этот трафик и из виртуальной машины могу прислать? И он положит всё и вся задолго до любого IDS.
Меня удивляет отношение индустрии к проблеме. Софтсвитч ведёт себя под нагрузкой как жидкое дерьмо, а все вокруг только и делают, что строят всё более и более сложные management решения.
Меня удивляет отношение индустрии к проблеме. Софтсвитч ведёт себя под нагрузкой как жидкое дерьмо, а все вокруг только и делают, что строят всё более и более сложные management решения.
Задача, которую решал автор данной статьи — обеспечение отказоустойчивости _элементов сети управления_, а не сети данных. При грамотном подходе к построению кластера из виртуалки вы контроллер не положите — в худшем случае потеряется вычислительная нода, не более того. Для защиты от злоумышленников изнутри необходимо применять совсем иные средства. Самое простое что приходит на ум — ограничение пропускной способности виртуального NIC средствами гипервизора или хост-системы, наверняка можно придумать и что-то поумнее — выбор в конечном итоге остается за вами как за архитектором кластера, стоит ориентироваться на специфику конкретной инсталляции. Короче говоря, суть вашей претензии не совсем ясна.
Другими словами, при «правильной» настройке виртуалки она будет сносить каждый из вычислительных узлов по-очереди.
Потрясающее решение, да.
Повторю ещё раз: пока снизу там не будет адекватного софта, можно хоть триста уровней тулстека накрутить, стабильно работать не будет.
Потрясающее решение, да.
Повторю ещё раз: пока снизу там не будет адекватного софта, можно хоть триста уровней тулстека накрутить, стабильно работать не будет.
Другими словами, при «правильной» настройке виртуалки она будет сносить каждый из вычислительных узлов по-очереди.
Из какой информации вы сделали столь неожиданный вывод?
Потрясающее решение, да.
Повторю ещё раз: пока снизу там не будет адекватного софта, можно хоть триста уровней тулстека накрутить, стабильно работать не будет.
Позвольте и мне повторить, «из коробки» в вопросах построения виртуальной вычислительной сети OpenStack опирается на штатные возможности сетевого оборудования и ОС вычислительных нод. Задачу обеспечения отказоустойчивости виртуальной сети OpenStack _не решает в принципе_. Хотите застраховаться от сетевых атак изнутри — выбирайте и настраивайте «адекватный софт» самостоятельно, поддержать его со стороны оркестратора большой проблемы не составит.
Sign up to leave a comment.
Обеспечение бесперебойности (HA) с платформой OpenStack: варианты топологий