Comments 55
Если не трудно, можете рассказать почему решили остановиться на salt?
Главная причина — человеческий фактор. Тяжеловесы puppet и chief более инертны, чем молодой проект salt. Плюс солт многопоточен (написан на питоне) — если паппет деплоит кластер за 50 секунд на какой-то задаче, то солт справится с аналогичной задачей секунд за 15-20, не более. Быстрая реакция вбагтреке. Думаю перечисленного достаточно. Да и все задачи, которые нам требуется решать, солт выполняет на 100%.
Анонс сети /24 может вызвать проблемы со связанностью, потому, что некоторые провайдеры фильтруют черезмерно короткие префиксы (а /24 считается коротким)
Коротким /24 не считается — это сеть класса С, а вот менее (например /28) — да.
Более-менее нормальным считается анонс от /22. Сеть /28 будет отфильтрована с почти 100% верноятностью.
Это как раз та самая граница.
/24 чаще всего проходит, но в рамках дефолтов. Всё, что меньше — фильтруется. Всё, что больше — проходит. Но зачастую, большие провайдеры и /24 фильтруют.
/24 чаще всего проходит, но в рамках дефолтов. Всё, что меньше — фильтруется. Всё, что больше — проходит. Но зачастую, большие провайдеры и /24 фильтруют.
/24 может не пройти, если в RIPE /23 не порубить на 2 по /24 — такое случалось. Да и не всех магистралов это качается — многие и /28 пропускают.
Как раз об этом и говорю.
Но если ваш магистрал пропускает /28, то это какой-то странный магистрал.
Очень странный.
Либо договорённость.
Но скорее всего, это просто странный магистрал =)
Но если ваш магистрал пропускает /28, то это какой-то странный магистрал.
Очень странный.
Либо договорённость.
Но скорее всего, это просто странный магистрал =)
А какие датацетры используете в своем проекте?
Спасибо за статью, было интересно почитать.
Посмотрел на Salt — с удивлением для себя понял, что она доступна только в платной пописке, и не OpenSource.
Посмотрел на Salt — с удивлением для себя понял, что она доступна только в платной пописке, и не OpenSource.
Уже хотел клянчить RPM, но всё оказалось намного проще :)
А что делает проект? Как-то цифры с буквами не сходятся.
Cisco ASR 1001 тянет 5Gbps. Один датацентр может тянуть весь траффик, то есть 5Gb = 640 MB в секунду. И это на миллион PPS (pages per second?)
получается 640 байт на страничку?
Даже если отвечать empty gif'ом, есть же ещё и входящий траффик с сотнями кук, SYN, ACK и т.д.
Тут на 30-40 тысяч запросов в секунду потребление трафика лезет в небо, а миллион…
Cisco ASR 1001 тянет 5Gbps. Один датацентр может тянуть весь траффик, то есть 5Gb = 640 MB в секунду. И это на миллион PPS (pages per second?)
получается 640 байт на страничку?
Даже если отвечать empty gif'ом, есть же ещё и входящий траффик с сотнями кук, SYN, ACK и т.д.
Тут на 30-40 тысяч запросов в секунду потребление трафика лезет в небо, а миллион…
Ну во-первых циска не одна) Вот описание проекта — tns-counter.ru/
Вот результаты — tns-global.ru/rus/data/ratings/index/index.wbp
Контент очень специфичный — приходит GET (пример можно посмотреть на том же Яндексе в теле любой страницы), отдаётся прозрачный gif и кука.
Вот результаты — tns-global.ru/rus/data/ratings/index/index.wbp
Контент очень специфичный — приходит GET (пример можно посмотреть на том же Яндексе в теле любой страницы), отдаётся прозрачный gif и кука.
Если у Вас 2-3-4 сервера, конечно Вы не будете разворачивать автоматизацию
Не так уж и «конечно». Даже при наличии одной вдски для какой-нибудь джумлы на средства автоматизации деплоя как самого сервера, так и приложения, стоит посмотреть именно в целях минимизации простоев при отказах — даже для виртуалки в супер-пупер облаке может потребоваться быстро развернуть второй аналогичный инстанс. А надеясь на записи или, тем более, память, легко получить ситуацию «вроде всё то же самое, но почему-то не работает».
Пускай это даже будет самописный шелл-скрипт, в котором всё захардкожено и ничего не прокомментировано и который даже нельзя без внимания оставить, потому что будет спрашивать "?(yes/no)" постоянно, но немало нервов и/или денег он может спасти. Главное поддерживать его в актуальном состоянии, для чего есть разные методики, но самая простая — ничего не делать на сервере ручками.
Только не следует забывать, что инструменты деплоя и бэкапа служат для разных целей и не стоит на один накладывать функции второго, использовать их следует совместно, но совсем необязательно в рамках одной «сессии», хотя лично у меня типичный сценарий восстановления: задеплоили среду (установили весь софт из публичных репов, условно, репов ОС), задеплоили приложение (из своего приватного репа), накатили бэкап данных приложения (база и пользовательские файлы типа аватарок, фоток или документов).
Единственный нюанс с которым мы столкнулись — по-умолчанию IPVS готов принимать 4096 одновременных соединений — это 2 бита.
Чтобы балансировщик был готов принимать миллион соединений этот параметр нужно увеличить до 12 битов.
Кол-во соединений ограничено доступной памятью, а 4096 — это размер хеш таблицы для соединений. Не понятно что такое 2 бита. Если вы имеете ввиду этот параметр
CONFIG_IP_VS_TAB_BITS
, который задает размер хеш-таблицы размером 2^CONFIG_IP_VS_TAB_BITS, то он и так 12 бит.
Хотя для систем, обрабатывающих большое кол-во соединений, я бы его увеличил. С одной стороны у нас чуть больше будет вымываться кеш, но с другой стороны мы получим сильный прирост в производительности, так как для лукапа соединения в среднем придется итерировать по более коротким связным спискам.
Да, tab_bits. По-умолчанию значение этого параметра = 2.
Выходит наложение патча не влияет на ограничение по количеству соединений?
Если речь идет об изменении CONFIG_IP_VS_TAB_BITS, то оно не влияет на максимальное кол-во соединений, на это влияет только кол-во доступной ядру памяти.
IP_VS_TAB_BITS — IPVS connection table size (the Nth power of 2).
Вы пропустили ключевое слово hash. Это размер для хеш таблицы коннектов, сами коннекты аллоцируются динамически и добавляются в связные списки, по одному (списку) в каждый бакет хеш таблицы.
Вы бы лучше открыли код, я ж давал выше ссылку в нужное место.
Таблица аллоцируется тут
ip_vs_conn_tab = vmalloc(ip_vs_conn_tab_size * sizeof(*ip_vs_conn_tab));
внутри функции с говорящим названием ip_vs_conn_init
где ip_vs_conn_tab_size это размер хеш таблицы
static int ip_vs_conn_tab_bits = CONFIG_IP_VS_TAB_BITS;
ip_vs_conn_tab_size = 1 << ip_vs_conn_tab_bits;
А ip_vs_conn_tab — указатель но голову списка
static struct hlist_head *ip_vs_conn_tab __read_mostly;
Убедил? =)
Вы бы лучше открыли код, я ж давал выше ссылку в нужное место.
Таблица аллоцируется тут
ip_vs_conn_tab = vmalloc(ip_vs_conn_tab_size * sizeof(*ip_vs_conn_tab));
внутри функции с говорящим названием ip_vs_conn_init
где ip_vs_conn_tab_size это размер хеш таблицы
static int ip_vs_conn_tab_bits = CONFIG_IP_VS_TAB_BITS;
ip_vs_conn_tab_size = 1 << ip_vs_conn_tab_bits;
А ip_vs_conn_tab — указатель но голову списка
static struct hlist_head *ip_vs_conn_tab __read_mostly;
Убедил? =)
А зачем, имея /23, заморачиваться с EXIST_MAP?
Ведь можно с каждой площадки отдавать /23 и свою /24. Тогда если вторая площадка отвалится, пропадёт её /24 и клиенты потекут на первую через /23 маршрут.
Ведь можно с каждой площадки отдавать /23 и свою /24. Тогда если вторая площадка отвалится, пропадёт её /24 и клиенты потекут на первую через /23 маршрут.
Я же писал, что на кваге и так можно реализовать с разнымы весами на /24 и /23, но у нас вот так.
Под весами подразумевалась длина префиксов? Тогда пардон, не понял. У меня вес как-то проассоциировался с параметром weight.
И уточните, пожалуйста, что за параметр у Juniper при меньше 20 секунд считается фладом? Время, которое проходит между потерей маршрута и анонсом этой потери соседу по BGP, или что?
И уточните, пожалуйста, что за параметр у Juniper при меньше 20 секунд считается фладом? Время, которое проходит между потерей маршрута и анонсом этой потери соседу по BGP, или что?
Да да, описался. Про параметр Juniper-а не отвечу, так как он у нас в одном из ДЦ аплинком и не принадлежит нам -естественно доступа на него нет. У нас в хозяйстве только Cisco.
Скорее всего имелось ввиду это BGP Flap Damping
А какие коммутаторы в ДЦ используете?
Cisco Catalyst 3750-X
А почему выбран именно этот коммутатор?
И еще вопрос
«Как только мы видим из второго ДЦ, что связанность нарушена, мы начинаем с помощью NON-EXIST-MAP анонсировать вторую сеть /24 из первого ДЦ.»
А возможна у вас ситуация split-brains, то есть первый ДЦ думает что второй лежит и наборот? Если да, каким образом планируется из нее выходить?
И еще вопрос — чем вы все это мониторите?
И еще вопрос
«Как только мы видим из второго ДЦ, что связанность нарушена, мы начинаем с помощью NON-EXIST-MAP анонсировать вторую сеть /24 из первого ДЦ.»
А возможна у вас ситуация split-brains, то есть первый ДЦ думает что второй лежит и наборот? Если да, каким образом планируется из нее выходить?
И еще вопрос — чем вы все это мониторите?
А почему выбран именно этот коммутатор?
Даже не задумывались. Как бы я не ответил на этот вопрос — будет воспринято неоднозначно.
А возможна у вас ситуация split-brains
Очень маленький процент, включающий в себя отказ сразу одновременно нескольких точек мониторинга. Для этого существует многоступенчатый мониторинг, включающий не только опросы по сети, а и GSM модемы и пр.
чем вы все это мониторите?
Ничего удивительного — snmp, zabbix, графики — cacti
Фраза «PPS в секунду» звучит примерно как «км/ч в час».
Дмирий, спасибо за упоминание Salt. Очень понравилась эта система.
Я бы сказал больше, но это уже будет глубоко ненормативная лексика — настолько велик мой восторг :)
Я бы сказал больше, но это уже будет глубоко ненормативная лексика — настолько велик мой восторг :)
Крайне интересно было бы услышать про тестирование такой системы.
Ну что, господа, начинаем бузить) Мы сделали свой прототип DCaaS.
Sign up to leave a comment.
Миллион PPS в секунду — связанность и балансировка