Що ми робимо · Мережа: Fabric дата-центру: EVPN/VXLAN на Cisco Nexus
Усередині Digital Realty Athens кожен сервер, blade-шасі, хост сховища і клієнтський firewall, який ми експлуатуємо, підключений до fabric Cisco Nexus 9000 leaf і spine з BGP EVPN та VXLAN. Кожен хост підключений подвійно, будь-який VLAN може жити на будь-якому leaf, а ваш шлюз має однакову адресу всюди, тож навантаження переїжджають і перемикаються без зміни адресації.
Що це
Fabric Clos: spine зверху, пари leaf знизу, border leaf передають маршрутизований трафік нашим edge-маршрутизаторам. EVPN є площиною керування, тож комутатори дізнаються, де живе кожна адреса, через BGP, а не розсилаючи трафік усім, щоб з’ясувати. VXLAN переносить кожен сегмент Layer 2 через fabric, а це означає, що ваша мережа не прив’язана до стійки, в якій випадково стоїть ваш сервер.
Як ми це будуємо
- Spine як чисті route reflector. На spine за задумом немає жодних кінцевих точок тунелів.
- Leaf у парах vPC. Сервери підключаються через LACP port-channel, які є справжніми віртуальними port-channel через обидва комутатори пари.
- Детермінована кабельна розводка blade. Шасі HPE c7000 підключаються через fabric extender Cisco Nexus 2000, по одному на кожну сторону fabric.
- Anycast-шлюзи. На кожному leaf.
- Без залежності від multicast. Широкомовний і невідомий трафік реплікується через BGP ingress replication, що тримає underlay простим і передбачуваним.
- Правило нумерації, яке контролює машина. Ідентифікатор VXLAN кожного сегмента виводиться з його локального VLAN за фіксованим правилом, з явними route target. Автоматична перевірка щогодини зчитує повну карту з кожного leaf, підтверджує, що leaf ідентичні та дотримуються правила, і порівнює криптографічний відбиток усієї карти з підписаним еталоном у системі контролю версій. Відхилення викликає інженера. Заплановану зміну потрібно підписати заново, тож кожна зміна fabric має автора та аудиторський слід.
- Нативна маршрутизація для контейнерних платформ. Кластери Kubernetes і OpenShift анонсують публічні адреси своїх сервісів у fabric через eBGP з кожного вузла на обидва leaf його пари, з BFD для виявлення відмови менш ніж за дві секунди і з prefix list, звуженими до точних маршрутів хостів.
- Bond, які використовують обидва лінки. Кожен bond-сервер, який ми будуємо, хешує за layer 3 і layer 4, а сторона комутатора налаштована відповідно, тож паралельні потоки справді розподіляються між обома членами.
Від чого це вас захищає
- Від відмови одного комутатора, лінка, fabric extender чи NIC, через яку ваш хост іде в офлайн.
- Від помилково введеного ідентифікатора VLAN чи VXLAN, що непомітно з’єднує мережі двох клієнтів.
- Від повільного перемикання, коли публічна адреса переїжджає хвилинами замість секунд.
- Від рутинного додавання VLAN, що знімає наявні VLAN з живого trunk.
- Від того, що ви платите за два лінки, а користуєтеся одним.
На практиці
Перемикання, доведене тестом. У контрольованому тесті відмови ми перезавантажили вузол контейнерного кластера, поки він був пріоритетним шляхом для живої публічної адреси. Fabric зійшлася на здоровий вузол приблизно за три секунди, а публічна адреса жодного разу не зникла з таблиці маршрутизації fabric.
Blade-стійка, скомутована до прибуття blade. Перед запуском нових клієнтських платформ ми побудували повну топологію port-channel і vPC для цілої blade-стійки за один підхід, ще до того, як більшість blade фізично існувала. Кожен кластер баз даних розмістили так, щоб кожна репліка була в іншому шасі, тож жодне окреме шасі не може зламати кворум. День запуску був увімкненням живлення, а не роботою з кабелями.
Обидва лінки кожного bond у роботі. Після кожної збірки з bond ми зчитуємо лічильники на портах, щоб довести, що трафік ідуть обома лінками.
Чому EuroVPS
- Справжня fabric EVPN/VXLAN на Cisco Nexus 9000, та сама архітектура, яку експлуатують великі підприємства та оператори зв’язку.
- Подвійне підключення для кожного хоста, а не лише для дорогих.
- Ізоляція клієнтів, яку щогодини перевіряє машина за підписаним описом того, якою має бути fabric.
- Ingress контейнерів маршрутизується нативно з BFD, а не причеплений через один балансувальник.
Часті запитання
Чи ізольований мій трафік від інших клієнтів? Так. Ваші сегменти мають власні ідентифікатори та route target, а щогодинна перевірка цілісності існує саме для того, щоб випадкове з’єднання між клієнтами неможливо було не помітити.
Що станеться, якщо відмовить комутатор? Ваш сервер підключений bond через обидва комутатори пари, а ваш шлюз існує на кожному leaf. Трафік продовжує йти через вцілілий комутатор.
Чи можу я мати власні VLAN і підмережі? Так. Виділені сегменти та публічні підмережі будуються як anycast-шлюзи по всій fabric, не торкаючись чиєїсь іншої конфігурації.
Чи може мій кластер Kubernetes анонсувати власні адреси сервісів? Так. Ми встановлюємо пірингову сесію кожного вузла з fabric через eBGP з BFD, тож вузол, що відмовив, обходиться за секунди.
Якщо ви хочете, щоб ваші сервери стояли на fabric, яку будують і перевіряють саме так, поговоріть з інженером.
Ваш наступний партнер з інфраструктури
Погляньмо на вашу інфраструктуру.
Розкажіть, що ви запускаєте сьогодні і що потребує покращення. Інженер розгляне ваш запит і допоможе спланувати наступний крок.
+357 222 32280
Почнімо з вашої інфраструктури.
Трохи контексту допомагає нам почати правильну розмову.