Azure SDN
Разбираюсь, как работают сети в Azure Stack HCI - не потому, что собираюсь эту штуку строить (вряд ли в ближайшее время обломится такой случай, а жаль), а потому, что это проливает свет на то, как работает SDN в настоящем облаке Микрософт Лазурь.
Выясняются интересные подробности. Скажем, в Амазоне load balancer, если его раскидать по разным availability zones, создаёт по IP-адресу в каждой (то есть выделятся по виртуальной машине: HyperPlane в случае NLB, что-то более специализированное для ALB) - и далее полагается на DNS round-robin в качестве механизма HA. А Ажур при этом выделяет один адрес, и в ус не дует - и меня давно интриговало, как же при этом обеспечивается защита от падения всей зоны? Через VRRP, что ли?
Оказывается, всё просто - ажурный LB тоже состоит из множества виртуалок в разных зонах, и они разговаривают с физическими раутерами по BGP, при этом рекламируя один и тот же адрес (то, что называется anycast). Если зона падает, то трафик автоматически переключается на другую.
(Интересно, неужели вся эта туева хуча префиксов /32 попадает в BGP full view? Или Микрософт их всё же убирает из своей раздачи на выходе из своих AS?)
Это заодно и объясняет, почему для каждого Private Endpoint создаётся отдельный префикс /32 в раут-таблицах - работает-то Private Link именно через Standard Load Balancer.
Ещё два примечательных момента:
В отличие от всяких обычных LB (ну там, nginx / HAProxy/ F5 / FortiGate), ажурный LB не занимается переводом destination IP из своего в адрес конечной виртуальной машины (то есть DNAT): он отправляет на неё пакет как он есть. А как же виртуалка его принимает? А потому, что этот перевод выполняет сам гипервизор! ну то есть его виртуальный свитч. А потом выполняет обратный перевод (SNAT) для пакетов в обратном направлении - и благодаря этому эти пакеты вообще не проходят через виртуалку LB, что увеличивает её производительность. Происходит то, что называется direct server return, DSR.
(Это и объясняет, почему для ажурного LB невозможно задать отдельный network security group, NSG.)
Для приватных LB, где трафик приходит не с Интернета, а из других виртуалок, всё ещё круче - лишь первый пакет потока проходит через виртуалку LB. Дальнейший трафик идёт напрямую между физическими серверами, хостящими виртуалку-клиент и виртуалку-сервер (а если они обе на одном, так он и вообще за пределы сервера не выходит).
Amazon NLB, подозреваю, работает так же. Всё это возможно, конечно, благодаря тому, что живут они не в обычных сетях, а в SDN, где правила пересылок программируются напрямую на физических серверах.
Это же позволяет решить проблему масштаба. В чём проблема традиционных сетей? Допустим, у нас есть датацентр о 200 серверах. На них куча виртуальных машин и сетей. Как мы позволяем виртуалке в сети А на одном сервере общаться с другими виртуалками в той же сети на любых других серверах?
Ну как, подключаем все эти сервера к соединённым промеж собой свитчам, определяем VLAN-ы. Будем простоты ради считать, что любой порт на свитче - VLAN trunk, и любой пакет с меткой A может быть доставлен любому серверу.
А как эти виртуалки друг друга находят? Ну, классика, ARP - посылаем широковещательный запрос "эй, у кого IP-адрес такой-то?" Свитчи доставляют этот broadcast на все сервера, те фильтруют по меткам своих VLAN-ов, а то и по запрошенному IP, нужная машина получает ARP-запрос и отвечает на него, дальнейший трафик идёт уже лишь по нужным портам и свитчам.
А если у нас облако и уже не 200 серверов, а 20000? Тоже каждому доставлять каждый broadcast? Проблема.
А SDN эту проблему решает. Нету broadcast-ов внутри виртуальных сетей, зато есть заранее известный SDN-контроллеру расклад, на каких серверах сидят какие виртуалки с какими адресами. И этот контроллер просто задаёт заранее правила каждому из этих серверов: если в виртуальной сети A посылается пакет на IP-адрес виртуалки X, сидящей на сервере Z - то просто запакуй его во внешний пакет с адресом Z и с меткой сети A, и пошли прямо на сервер Z. Чтобы найти сервер Z, broadcast используется, но масштаб уже совсем не тот, тем более, что эти 20000 ничто не мешает распихать по разным VLAN-ам да сабнетам.
В общем, интересное кино.
Выясняются интересные подробности. Скажем, в Амазоне load balancer, если его раскидать по разным availability zones, создаёт по IP-адресу в каждой (то есть выделятся по виртуальной машине: HyperPlane в случае NLB, что-то более специализированное для ALB) - и далее полагается на DNS round-robin в качестве механизма HA. А Ажур при этом выделяет один адрес, и в ус не дует - и меня давно интриговало, как же при этом обеспечивается защита от падения всей зоны? Через VRRP, что ли?
Оказывается, всё просто - ажурный LB тоже состоит из множества виртуалок в разных зонах, и они разговаривают с физическими раутерами по BGP, при этом рекламируя один и тот же адрес (то, что называется anycast). Если зона падает, то трафик автоматически переключается на другую.
(Интересно, неужели вся эта туева хуча префиксов /32 попадает в BGP full view? Или Микрософт их всё же убирает из своей раздачи на выходе из своих AS?)
Это заодно и объясняет, почему для каждого Private Endpoint создаётся отдельный префикс /32 в раут-таблицах - работает-то Private Link именно через Standard Load Balancer.
Ещё два примечательных момента:
(Это и объясняет, почему для ажурного LB невозможно задать отдельный network security group, NSG.)
Amazon NLB, подозреваю, работает так же. Всё это возможно, конечно, благодаря тому, что живут они не в обычных сетях, а в SDN, где правила пересылок программируются напрямую на физических серверах.
Это же позволяет решить проблему масштаба. В чём проблема традиционных сетей? Допустим, у нас есть датацентр о 200 серверах. На них куча виртуальных машин и сетей. Как мы позволяем виртуалке в сети А на одном сервере общаться с другими виртуалками в той же сети на любых других серверах?
Ну как, подключаем все эти сервера к соединённым промеж собой свитчам, определяем VLAN-ы. Будем простоты ради считать, что любой порт на свитче - VLAN trunk, и любой пакет с меткой A может быть доставлен любому серверу.
А как эти виртуалки друг друга находят? Ну, классика, ARP - посылаем широковещательный запрос "эй, у кого IP-адрес такой-то?" Свитчи доставляют этот broadcast на все сервера, те фильтруют по меткам своих VLAN-ов, а то и по запрошенному IP, нужная машина получает ARP-запрос и отвечает на него, дальнейший трафик идёт уже лишь по нужным портам и свитчам.
А если у нас облако и уже не 200 серверов, а 20000? Тоже каждому доставлять каждый broadcast? Проблема.
А SDN эту проблему решает. Нету broadcast-ов внутри виртуальных сетей, зато есть заранее известный SDN-контроллеру расклад, на каких серверах сидят какие виртуалки с какими адресами. И этот контроллер просто задаёт заранее правила каждому из этих серверов: если в виртуальной сети A посылается пакет на IP-адрес виртуалки X, сидящей на сервере Z - то просто запакуй его во внешний пакет с адресом Z и с меткой сети A, и пошли прямо на сервер Z. Чтобы найти сервер Z, broadcast используется, но масштаб уже совсем не тот, тем более, что эти 20000 ничто не мешает распихать по разным VLAN-ам да сабнетам.
В общем, интересное кино.