Как стать автором
Обновить

Комментарии 55

Если не трудно, можете рассказать почему решили остановиться на salt?
Главная причина — человеческий фактор. Тяжеловесы puppet и chief более инертны, чем молодой проект salt. Плюс солт многопоточен (написан на питоне) — если паппет деплоит кластер за 50 секунд на какой-то задаче, то солт справится с аналогичной задачей секунд за 15-20, не более. Быстрая реакция вбагтреке. Думаю перечисленного достаточно. Да и все задачи, которые нам требуется решать, солт выполняет на 100%.
Полагаю, что прироста в скорости уже достаточно.
Посмотрите еще ansible — тоже очень хорошая система и, главное, она простая и предсказуемая. Тоже на питоне.
Анонс сети /24 может вызвать проблемы со связанностью, потому, что некоторые провайдеры фильтруют черезмерно короткие префиксы (а /24 считается коротким)
Коротким /24 не считается — это сеть класса С, а вот менее (например /28) — да.
Более-менее нормальным считается анонс от /22. Сеть /28 будет отфильтрована с почти 100% верноятностью.
Это как раз та самая граница.
/24 чаще всего проходит, но в рамках дефолтов. Всё, что меньше — фильтруется. Всё, что больше — проходит. Но зачастую, большие провайдеры и /24 фильтруют.
/24 может не пройти, если в RIPE /23 не порубить на 2 по /24 — такое случалось. Да и не всех магистралов это качается — многие и /28 пропускают.
Как раз об этом и говорю.
Но если ваш магистрал пропускает /28, то это какой-то странный магистрал.
Очень странный.
Либо договорённость.
Но скорее всего, это просто странный магистрал =)
Наши не пропускают)
Отчего же??
Вот кто по простой договорённости пропускает:
AS48625, AS50952, AS56336, AS43106, AS39792, AS9002, AS29076, AS8359…
Ну эт так, на вскидку.
Ещё RunNet (AS не помню) легко.
ТТК, Голды, Прометей — по письму.
Когда я писал «наши» — я имел в виду те, с кем мы работаем напрямую, а не «Российские»
Ну, пардоньте =)
Под нашими я понимаю именно «наших».
Кстати, вот именно с операторами РФ легче всего договориться, нежели с операторами европейскими.
А какие датацетры используете в своем проекте?
stack.net и MSK-IX М9
Спасибо за статью, было интересно почитать.
Посмотрел на Salt — с удивлением для себя понял, что она доступна только в платной пописке, и не OpenSource.
Уже хотел клянчить RPM, но всё оказалось намного проще :)
А что делает проект? Как-то цифры с буквами не сходятся.
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 и кука.
Если у Вас 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.
Хм, странно, посмотрел вплоть до 2.6.32, везде 12 бит, у вас на картинке вроде тоже (log 4096), ну да не суть. =)
да, 4096 — это и есть 2 бита. 12 бит — это помоему 1048576.
Выходит наложение патча не влияет на ограничение по количеству соединений?
Если речь идет об изменении 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;
Убедил? =)
Да.
А зачем, имея /23, заморачиваться с EXIST_MAP?
Ведь можно с каждой площадки отдавать /23 и свою /24. Тогда если вторая площадка отвалится, пропадёт её /24 и клиенты потекут на первую через /23 маршрут.
Я же писал, что на кваге и так можно реализовать с разнымы весами на /24 и /23, но у нас вот так.
Под весами подразумевалась длина префиксов? Тогда пардон, не понял. У меня вес как-то проассоциировался с параметром weight.
И уточните, пожалуйста, что за параметр у Juniper при меньше 20 секунд считается фладом? Время, которое проходит между потерей маршрута и анонсом этой потери соседу по BGP, или что?
Да да, описался. Про параметр Juniper-а не отвечу, так как он у нас в одном из ДЦ аплинком и не принадлежит нам -естественно доступа на него нет. У нас в хозяйстве только Cisco.
Скорее всего имелось ввиду это BGP Flap Damping
Да, я тоже так предположил, потому и удивился. Эта функция ведь отключается. И выключена по умолчанию.
Да, по умолчанию выключена, но на EBGP пирах ее все же рекомендуют включать.
У нас этим занимается отдельный сотрудник — сетевой инженер, но термин «зафлапали» я слышал.
А какие коммутаторы в ДЦ используете?
Cisco Catalyst 3750-X
А почему выбран именно этот коммутатор?

И еще вопрос
«Как только мы видим из второго ДЦ, что связанность нарушена, мы начинаем с помощью NON-EXIST-MAP анонсировать вторую сеть /24 из первого ДЦ.»

А возможна у вас ситуация split-brains, то есть первый ДЦ думает что второй лежит и наборот? Если да, каким образом планируется из нее выходить?

И еще вопрос — чем вы все это мониторите?
А почему выбран именно этот коммутатор?

Даже не задумывались. Как бы я не ответил на этот вопрос — будет воспринято неоднозначно.

А возможна у вас ситуация split-brains

Очень маленький процент, включающий в себя отказ сразу одновременно нескольких точек мониторинга. Для этого существует многоступенчатый мониторинг, включающий не только опросы по сети, а и GSM модемы и пр.

чем вы все это мониторите?

Ничего удивительного — snmp, zabbix, графики — cacti
Фраза «PPS в секунду» звучит примерно как «км/ч в час».
Может, автор об ускорении говорит. Трафик растет типа.
1000000 pps/s — это, простите, пипец…
Дмирий, спасибо за упоминание Salt. Очень понравилась эта система.
Я бы сказал больше, но это уже будет глубоко ненормативная лексика — настолько велик мой восторг :)
Разработчики позиционируют ее как remote execute систему кстати, а не deploy. Я уже давно не захожу на машины — все делаю с сервера деплоя из строки salt.
В моем случае я смотрю на эту систему, как на альтернативу связке Puppet+MCollective. Так что как раз попадаю в ЦА авторов :)
Для Puppet remote execute как альтернативу Mcollective можно использовать например fabric + puppetdb — довольно удобно.
Наверно вопрос не ко мне, но имхо salt симпатичнее, но сильно молодой. Для уровня проекта пойдет, но не enterprise wide. Хотя смотря какой enterprise конечно…
Крайне интересно было бы услышать про тестирование такой системы.
В процессе. Готово процентов на 60%. Рвусь между сравнительной статьёй и статьёй про SALT.
Ну что, господа, начинаем бузить) Мы сделали свой прототип DCaaS.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.