В рамках выступления на BEER в Минске затронул тему вреда* конференций типа Highload.
Представим себе молодого айтишника (даже пока еще не специалиста), попавшего на Хайлоад и услышавшего как Яндекс строит свою сеть.
Сам этот айтишник, увы, с классическим дизайном сети не знаком, сети никогда ранее не строил, и вообще не очень отличает VLAN от подсети. Раумеется, Яндекс компания с огромной сетью и штатом специалистов, а значит они уж точно знают как надо строить сети. Правоту Яндекса подчеркивает то, что сети Гугла и Амазона построены по практически тем же принципам.
И вот наш молодой специалист начинает на этой волне подходов гиперскейлеров внедрять подходы у себя в организации. Олифера не читал, CCNA не получал, классику в Core-Distribution-Access никогда не строил и даже не изучал.
Итог: сделаем L3 Spine Leaf, L2 только в пределах стойки. При помощи этого подхода можно вырасти до десятков тысяч стоек! Круто же!
Но вот насколько нужен этот подход, если в организации сейчас 5 стоек оборудования, при том, что они заполнены лишь наполовину из-за ограничения по мощности? И в ближайшие 5 лет может быть, лишь может быть организация вырастет до 8. А может и схлопнется до 4х из-за роста удельной вычислительной мощности и емкости хранения на 1U / кВт.
Т.е. никогда не придется это организации воспользоваться теми преимуществами, что предлагает данный подход. Зато полностью со всеми ограничениями и сразу.
Мы хотим добавить несколько серверов в кластер гипервизоров из соседней стойки. Ан нет, борода тебе бабка. Никаких живых миграций в пределах кластера у тебя не будет. Да и холодных тоже. В соседней стойке другая L3 сеть, а для живой миграции нужна единая L2 - машина нагрузки IP не может менять.
Да, проблема решается поднятием L2overL3 оверлея и SDN в соседнюю стойку. Но какой ценой? Сколько нужно софта, регламентов, проектирования, и специалистов для реализации того, что в классике делается вообще одним специалистом средней руки в варианте Collapsed Core (Core-Access) и L2 между стойками. Да, здесь есть пределы масштабирования, и при росте инфраструктуры нужно будет перепроектировать, но так а будет ли этот рост? И до каких пределов - на пару стоек, на пару десятков стоек или до сотен и тысяч?
Для понимания - еще несколько лет назад размер среднего облачного провайдера в РФ (не берем монстров калибра Даталайна) составлял 2-3 стойки оборудования в колокейшен. Это специализированной айти компании, которая предоставляет сервисы и ресурсы для обычных компаний уровня SMB, не из айти.
Или поясню по аналогии. Если есть потребность возить картошку, то весь вопрос в том, СКОЛЬКО ее надо возить. Один мешок картошки можно кинуть в багажник Жигулей. 2 мешка тоже. 10 мешков можно отвезти на Жигулях за два раза. Для 50 возьмем Газель.
Если надо возить 500-1000 мешков в день, то купим пару-тройку грузовиков. При 10000+ необходимо уже строить гараж, сервис, нанимать водителей подмены и вообще всерьез организовывать траспортную часть.
Яндекс возит по 100 тыс мешков в день и рассказывает как именно организовал найм водителей, следит за машинами на линии, в чем разница между Сканией и Камаз Нео.
А слушают это люди, которым вполне хватит Газели. Одной.
И это не придуманный кейс с L3LS, это реальная проблема в некоторых случаях. Стоимость, сложность и отсутствие оверлея для реализации L2 между стойками.
Что нам ответят сетевики новой формации? Окай бумер, твоя легаси не вписывается в новые модные сети. Это твои проблемы, зато у нас сети красивые.
Что ответят девопсы? Окай бумер, твоя легаси не вписывается в клауд-нейтив. Это твои проблемы, переписывай на клауд-нейтив.
Это как раз та самая проблема, о которой я говорю почти на каждой конференции. Разрыв между бизнесом и технарями. Технари заняты исключительно своей собственной технической частью и ее красотой - чтобы как у больших мальчиков в Яндексе все было. А бизнесу все равно, бизнесу нужны риски в деньгах и стоимость. Но вот про стоимость технарям не интересно, и что в масштабах Яндекса количество переходит в качество, и управляемость сети в пределах десятков тысяч стоек важнее, а в схему работы продуктов и инфраструктуры Яндекса все это заложено еще на этапе проектирования.
Давайте делать как у них, а если у нас что не взлетает - ну ничего, уволюсь и пойду в другую контору, сейчас дефицит кадров. А читать устаревшего Олифера или изучать как там работает легаси? Не, мы ж не бумеры.
Часть 2.
По вопросу L2 over L3 в соседнюю стойку ко мне приехала специальная пояснительная бригада. Точнее сразу несколько.
Бригада номер один пояснила, что не надо никакого L2, а надо делать pure L3 через /31 сети, чтобы каждая ВМ была одна в своей L3 и могла бегать куда хочет. А эти ваши подсети /24 или, упаси Ньютон, /22 - безнадежно устарели.
Бригада номер два пояснила, что это вообще нормально. Админ за счет работодателя развивается и играет в свои технические игрушки. Ачотакова?
Бригада номер три повторила тезис "страшно тебе, тупой бумер, ахаха лол кек" и убежала, крикнув в дверях "изи катка".
Возвращаемся к вопросу выбора архитектуры. Как уже было описано в "Общей теории <strike>всего</strike> проектирования виртуального датацентра", сначала мы собираем полный комплект бизнес требований в виде RPO, RTO и прочих $/час простоев. После чего пишем документ "Модель угроз" ("Матрица рисков"), в котором указываем все риски, от которых будем защищаться.
- Любой случайно влетевший дятел аффектит весь домен: что vm решила что она dhcp, что proxy arp там же.
Вот именно это должно быть написано в матрице рисков с проставленными весами.
И лишь ПОСЛЕ этого, берутся несколько вариантов реализации архитектуры, и сравниваются по матрице рисков, а затем по экономике.
И таки да, если экономика побеждает, а матрица рисков пропускает только эту архитектуру, то она стандартизуется в виде платиново-иридиевого стандарта.
Именно поэтому в рамках гиперскейлеров есть расчеты и обоснования почему там нет L2 между стойками и почему управляемость и масштабируемость важнее некоторых неудобств. В случае с инфраструктурой в 3 стойки обычно ничего этого нет, но есть играющий в технические игрушки админ. У которого есть защитная реакция, он защищает свою личную песочницу и свои хотелки от вторжений извне и попыток контроля.
Только вот админ забывает, что это не личная песочница, и это не его личные серверы. Это серверы компании, которые приносят этой компании деньги, а админ их лишь обслуживает.
- В *МОЕЙ* сети Нексусов не будет! - один из руководителей сетевого отдела крупной компании (реальная цитата)
Конечно, админы и сетевики далеко не единственные с подобным поведением. Вы же замечали ту же самую историю скажем в бухгалтерии?
Задача бухгалтера - это документальное оформление движения денег согласно требований законодательства, чтобы гендиректор не сел в тюрьму. Но крайне часто бухгалтеры начинают вести себя в первую очередь как контролеры. А именно:
- вместо помощи с оформлением как правильно - иди переделывай, вон инструкция. Вас тут много, а я одна
- а ну ка объясни куда это ты собрался и на что деньги потратил!
Как то раз мне пришлось потратить два часа и писать две объяснительных, чтобы доказать, что в гостинице в номере с двумя кроватями я жил один, проституток не водил, и вообще других номеров не было. Иначе мне бухгалтерия соглашалась оплатить только половину стоимости. "А вдруг ты там не один был?! Как оправдываться будешь?"