HighLoad++ 2017
Зал «Пекин + Шанхай», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2946.html
* Высокая нагрузка с точки зрения сетевого инженера.
* Паттерны в архитектуре на примере Facebook/Google.
* Многоуровневая балансировка L7, L4, L3. DNS.
* Принципы функционирования Anycast и особенности развертывания, методы стабилизации Anycast-сервисов.
* Особенности распределения сетевого трафика/подключений.
Как обслужить миллиард пользователей и отдать терабит трафика / Игорь Васильев (ПАО Сбербанк России)
1. Как обслужить миллиард пользователей и отдать
терабит трафика
ПАО Сбербанк России, Руководитель направления,
Отдел телекоммуникационной инфраструктуры Дата-Центров
Igor Vasiliev, CCIE No.: 19895
Электронная почта: iivasiliev@gmail.com
2. Краткий обзор
Тема данной презентации
Как обслужить миллиард пользователей и отдать терабит трафика
Основы балансировки
Такие сервисы, как Google, Facebook, Twitter, NetFlix, Linkedin и т.д. и т.п.,
применяют многоуровневые механизмы балансировки, которые
не ограничиваются конкретным уровнем модели OSI.1
Архитектура популярных Интернет-сервисов
Большинство Интернет-сервисов существует в пределах нескольких Центров
Обработки Данных, которые разбросаны по всему миру и представляют
собой распределенную архитектуру.2
CDN и Edge-узлы
Инфраструктура популярных Интернет-сервисов не ограничивается ЦОД, а так
называемые «Edge» узлы формируют некоторое подобие CDN-сети, которая
обеспечивает оптимальное распределение подключений.3
3. Закон Амдала
Краткое предисловие
Как обслужить миллиард пользователей и отдать терабит трафика
Task A Task B Task C Task D Task … Task Y Task Z
Последовательная часть Распараллеливаемая часть
Пользовательский запрос
1 процессор
Task A Task B
Task C
Task D
Task …
Task Y
Task Z
N процессоров
«В случае, когда задача разделяется на несколько частей, суммарное время её
выполнения на параллельной системе не может быть меньше времени выполнения
самого длинного фрагмента.»
4. Ultimate question of life the universe and everything
Как обслужить миллиард пользователей и отдать терабит трафика
Как обслужить миллиард пользователей и отдать терабит трафика
Anycast
5. Как работает Anycast?
Простой пример
Как обслужить миллиард пользователей и отдать терабит трафика
R6
IP: 10.0.0.254 IP: 80.0.0.1
10
10
10
10
10 10
10
U1
R2
R5
S1R4
U2R3 IP: 192.0.0.25
IP: 80.0.0.1 S2
R1
R7
Anycast для TCP приложений - это Challenge!
6. Как работает TCP?
Вспоминаем, как это работает
Как обслужить миллиард пользователей и отдать терабит трафика
Active
(Client)
Passive
(Server)
SYN, Seq = ISN(c), (Options)
ACK, Seq = L, ACK K + 1, (options)
SYN + ACK, Seq = ISN(s), ACK = ISN(c) +1, (options)
ACK, Seq = ISN(c) + 1, ACK = ISN(s) + 1, (options)
FIN + ACK, Seq = K, ACK = L, (options)
FIN + ACK, Seq = L, ACK = K + 1, (options)
ACK, Seq = K, ACK = L + 1, (options)
Connection Set-Up
(TCP Three-Way Handshake)
[No Data Transferred in This Example]
Data Transfer
(Established)
Connection Close
(Modified Three-Way
Handshake)
7. Основная проблема
TCP Reset и Session Persistance
Как обслужить миллиард пользователей и отдать терабит трафика
Host
Host
Host
Router
SYN
SYN/ACK
ACK
RST
TCP Reset
9. ECMP-балансировка
Балансировка между равнозначными маршрутами
Как обслужить миллиард пользователей и отдать терабит трафика
IP: 1.1.1.1
10
10
10
10
R2
R3
R1 R4
Хэширующая функция или планировщик
Балансировка между каналами
IP: 1.1.1.1 IP: 1.1.1.1
S2S1 S3
R1
Хэширующая функция
или планировщик
Балансировка между серверами
Потенциальная проблема
tcp out-of-order
Потенциальная проблема
tcp reset
10. ECMP-балансировка
Реализация в телекоммуникационном оборудовании
Как обслужить миллиард пользователей и отдать терабит трафика
000
001
010
011
100
101
110
111
Adjacency Table
PTR 0x01
PTR 0x02
PTR 0x03
PTR 0x04
PTR 0x05
PTR 0x06
PTR 0x07
PTR 0x08
67.1.31.1
187.1.1.6
134.1.2.1
8.222.1.6
Source IP
0x01 NEXT_HOP A IF 0x01 …
0x02 NEXT_HOP B IF 0x02 …
0x03 NEXT_HOP C IF 0x03 …
0x04 NEXT_HOP D IF 0x04 …
0x05 NEXT_HOP E IF 0x05 …
0x06 NEXT_HOP F IF 0x06 …
0x07 NEXT_HOP G IF 0x07 …
0x08 NEXT_HOP H IF 0x08 …
Hash Function
or
Scheduler
Hash Results
Lookup
Hash Bucket Adjacency Pointer
Hash Table
Hash Results
Lookup
XOR
or
other function
PTR NHOP Dst IP Intf DB
Required Information for Rewrite Engine
Other
Key Value
MRU RR
or
LRU RR
Mapping
Подробнее - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.6583&rep=rep1&type=pdf
SIGCOMM, Volume 34, Number 2: April 2004, Tree Bitmap: Hardware/Software IP Lookups with Incremental Updates
11. Хэш-функция
Алгоритмы балансировки
Как обслужить миллиард пользователей и отдать терабит трафика
Варианты балансировки
Существует два режима балансировки: per-packet и per-flow. Режим per-packet не
рекомендуется использовать, так как это может приводить к проблемам с TCP Out-Of-
Order и TCP Reset (обрыв подключения).1
Хэширующая функция
Представляет собой математическую операцию, которая основывается на таких
алгоритмах, как XOR или CRC. В некоторых случаях может использовать битовое
смещение. Влияет на распределение трафика. Результат хэш-функции предсказуем и не
изменчив.
2
Особенности реализаций
Некоторые устройства могут использовать дополнительные параметры (соль), которые
подмешиваются в математическую функцию алгоритма хэширования. Например,
устройства под управлением ОС Cisco IOS XR используют Router ID. Помогает бороться
с эффектом поляризации FIB.
3
12. Традиционный подход
Стандартный способ распределения ключей в хэш таблице
Как обслужить миллиард пользователей и отдать терабит трафика
000
001
010
011
100
101
110
111
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP D
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP D
Hash Bucket NHOP
Начальное состояние
Распределение ключей в хэш-таблице
Традиционный подход подразумевает под собой
динамическое распределение ключей внутри
существующей хэш-таблицы, которая может заполняться
по принципу MRU/LRU Round Robin.
Пример подобного распределения:
4:4
3:2:2
2:2:2:2
и т.д. и т.п.
Примеры реализаций
Большинство коммутаторов семейства Cisco Catalyst
(3XXX, 65XX), коммутаторы Cisco Nexus 7000 (F1/M1
карты) и т.д. и т.п.
Подробнее - https://www.cisco.com/c/en/us/support/docs/
lan-switching/etherchannel/12023-4.html
0001
0010
0011
0100
0101
0110
0111
1000
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP A
NEXT_HOP B
Hash Bucket NHOP
После отказа
Данное решение оказывает влияние на Anycast-трафик!
В этом примере будет перераспределено примерно
87% подключений. Для TCP-Aware Anycast это
большая проблема!
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP D
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP D
13. Консистентное хэширование
Рекурсивное распределение ключей
Как обслужить миллиард пользователей и отдать терабит трафика
000
001
010
011
100
101
110
111
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP D
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP D
Hash Bucket NHOP
Начальное состояние
Консистентное хэширование
Консистентное хэширование может быть основано на
рекурсивном распределении ключей внутри хэш-таблицы. Где
часть ключей (реальный ключ), содержит указатель на
конкретный NHOP, а другая часть ключей (виртуальный ключ)
ссылается на реальный ключ в таблице.
Поддерживается коммутаторами Mellanox (Spectrum ASIC),
Juniper, различные варианты WhiteBox (NPU Trident и выше) и
т.д. и т.п.
Ссылки по теме
Chord: A Peer-to-Peer Lookup Service for Internet Applications,
by I. Stoica, R. Morris, D. Karger, F. Kaashoek, H.Balakrishnan,
Proc. ACM SIGCOMM, San Diego, CA, September 2001.
Подробнее - https://docs.cumulusnetworks.com/display/DOCS/
Equal+Cost+Multipath+Load+Sharing+-
+Hardware+ECMP#EqualCostMultipathLoadSharing-
HardwareECMP-resilient_hashing
0001
0010
0011
0100
0101
0110
0111
1000
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP A
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP B
Hash Bucket NHOP
После отказа
Данное решение не оказывает влияние на Anycast-
трафик,так как существующие подключения не
затрагиваются. Оптимальное решение для TCP-Aware
Anycast!
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP D
NEXT_HOP A
NEXT_HOP B
NEXT_HOP C
NEXT_HOP D
14. Эффект поляризации FIB
Особенности ECMP-балансировки
Как обслужить миллиард пользователей и отдать терабит трафика
IP: 10.0.0.254
IP: 80.0.0.1
10
20
U2IP: 192.0.0.25
R6
10
10
10
10
10
R6
R1
R7
R2
U1
S1R4
Потенциальные графы для ECMP
Маршрут #1 R1 - R2 - R4 = 30
Маршрут #2 R1 - R7 - R6 - R4 = 30
Маршрут #3 R1 - R7 - R6 - R4 = 30
Нет трафика
Нет трафика
15. ECMP-балансировка
Топология Клоза и эффект поляризации FIB
Как обслужить миллиард пользователей и отдать терабит трафика
R3
R8
R1
R5R4
R2
R7
R6
R9
16. RACKA
ECMP-балансировка
Топология Клоза и эффект поляризации FIB
Как обслужить миллиард пользователей и отдать терабит трафика
IP: 1.1.1.1
IP: 10.0.0.1
R3
IP: 10.0.0.254
U1
R8
S2
RACKB
R1
R5R4
R2
IP: 1.1.1.1
IP: 10.0.0.2
R7
R6
S1
R9
17. RACKA
ECMP-балансировка
Топология Клоза и эффект поляризации FIB
Как обслужить миллиард пользователей и отдать терабит трафика
IP: 1.1.1.1
IP: 10.0.0.1
R3
IP: 10.0.0.254
U1
R8
S2
RACKB
R1
R5R4
R2
IP: 1.1.1.1
IP: 10.0.0.2
R7
R6
S1
R9
18. RACKA
ECMP-балансировка
Топология Клоза и эффект поляризации FIB
Как обслужить миллиард пользователей и отдать терабит трафика
IP: 1.1.1.1
IP: 10.0.0.1
R3
IP: 10.0.0.254
U1
R8
S2
RACKB
R1
R5R4
R2
IP: 1.1.1.1
IP: 10.0.0.2
R7
R6
S1
R9
19. RACKA
ECMP-балансировка
Топология Клоза и эффект поляризации FIB
Как обслужить миллиард пользователей и отдать терабит трафика
IP: 1.1.1.1
IP: 10.0.0.1
R3
IP: 10.0.0.254
U1
R8
S2
RACKB
R1
R5R4
R2
IP: 1.1.1.1
IP: 10.0.0.2
R7
R6
S1
R9
20. RACKA
ECMP-балансировка
Топология Клоза и эффект поляризации FIB
Как обслужить миллиард пользователей и отдать терабит трафика
IP: 1.1.1.1
IP: 10.0.0.1
R3
IP: 10.0.0.254
U1
R8
S2
RACKB
R1
R5R4
R2
IP: 1.1.1.1
IP: 10.0.0.2
R7
R6
S1
R9
21. RACKA
ECMP-балансировка
Топология Клоза и эффект поляризации FIB
Как обслужить миллиард пользователей и отдать терабит трафика
IP: 1.1.1.1
IP: 10.0.0.1
R3
IP: 10.0.0.254
U1
R8
S2
RACKB
R1R1
R5R4
R2
IP: 1.1.1.1
IP: 10.0.0.2
R7
R6
S1
R9
22. RACKA
ECMP-балансировка
Топология Клоза и эффект поляризации FIB
Как обслужить миллиард пользователей и отдать терабит трафика
IP: 1.1.1.1
IP: 10.0.0.1
R3
IP: 10.0.0.254
U1
R8
S2
RACKB
R1R1
R5R4
R2
IP: 1.1.1.1
IP: 10.0.0.2
R7
R6
S1
R9
24. RACKA
ECMP-балансировка
Топология Клоза и эффект поляризации FIB
Как обслужить миллиард пользователей и отдать терабит трафика
IP: 1.1.1.1
IP: 10.0.0.1
R3
IP: 10.0.0.254
U1
R8
S2
RACKB
R1R1
R5R4
R2
IP: 1.1.1.1
IP: 10.0.0.2
R7
R6
S1
R9
25. RACKA
ECMP-балансировка
Топология Клоза и эффект поляризации FIB
Как обслужить миллиард пользователей и отдать терабит трафика
IP: 1.1.1.1
IP: 10.0.0.1
R3
IP: 10.0.0.254
U1
R8
S2
RACKB
R1R1
R5R4
R2
IP: 1.1.1.1
IP: 10.0.0.2
R7
R6
S1
R9
Вывод первый
Топология и дизайн имеют значение. ECMP и Anycast
замечательно себя чувствуют в сетях Клоза (spine & leaf
архитектура).
Вывод второй
Эффект поляризации FIB - не всегда плохо. Он может
стабилизировать Anycast-трафик. Однако многое
зависит от физической топологии и дизайна сети.
Вывод третий
Требуется одинаковый режим балансировки на всех
устройствах Центра Обработки Данных. Например, per-
flow, 4 tuple (Source IP, Destination IP, Source Port,
Destination Port).
26. TCP SYN Proxy
Как обслужить миллиард пользователей и отдать терабит трафика
27. Асимметричная маршрутизация
Основные принципы маршрутизации трафика
Как обслужить миллиард пользователей и отдать терабит трафика
U
R2
S via R2
S via R3
S direct connected
SR1 R3
U via R1U direct connected
28. Традиционный подход - L2 DSR
Балансировка трафика с помощью Direct Server Return
Как обслужить миллиард пользователей и отдать терабит трафика
LB
S3 S4S1 S5S2S2
Physical: 10.0.0.1
Loopback: 1.1.1.1
Mac Addr: AAAAA
Physical: 10.0.0.2
Loopback: 1.1.1.1
Mac Addr: BBBBB
Physical: 10.0.0.3
Loopback: 1.1.1.1
Mac Addr: CCCCC
Physical: 10.0.0.4
Loopback: 1.1.1.1
Mac Addr: DDDDD
Physical: 10.0.0.5
Loopback: 1.1.1.1
Mac Addr: EEEEE
Physical: 10.0.0.6
Virtual IP: 1.1.1.1
Mac Addr: FFFFFF
U User IP: 80.0.0.9
VLAN X
VLAN Y
От клиента к балансировщику
IP адрес источника - 80.0.0.9
IP адрес назначения - 1.1.1.1
MAC адрес назначения - FFFFFF1
От балансировщика к серверу
IP адрес источника - 80.0.0.9
IP адрес назначения - 1.1.1.1
MAC адрес назначения - BBBBB2
От сервера к клиенту
IP адрес источника - 1.1.1.1
IP адрес назначения - 80.0.0.9
MAC адрес назначения - Шлюз по-умолчанию3
1
2
3
Потенциальные проблемы
Масштабируемость L2 сегментов
Broadcast flooding
L2 DCI и растянутые L2 сегменты
Неэффективная утилизация каналов связи (STP-блокировка
резервных подключений) и т.д. и т.п.
…
R1
29. S3S1
R2R3
LB
Full Routed DC - L3 DSR
Балансировка трафика с помощью Direct Server Return
Как обслужить миллиард пользователей и отдать терабит трафика
S2
Physical: 10.0.0.6
Tunnel IP: 40.0.0.6
Virtual IP: 1.1.1.1
U User IP: 80.0.0.9
S2
Physical: 10.1.0.1
Tunnel IP: 40.0.0.1
Loopback: 1.1.1.1
Physical: 20.2.0.2
Tunnel IP: 40.0.0.2
Loopback: 1.1.1.1
Physical: 30.3.0.3
Tunnel IP: 40.0.0.3
Loopback: 1.1.1.1
VLAN X VLAN Y VLAN Z VLAN B
VLAN A
1
2
3
4
От клиента к балансировщику
IP адрес источника - 80.0.0.9
IP адрес назначения - 1.1.1.1
Тип инкапсуляции - Plain IP1
Туннель между балансировщиком и сервером
IP адрес источника - 10.0.0.6
IP адрес назначения - 20.2.0.2
Тип инкапсуляции - IPIP/GRE Tunnel2
От балансировщика к серверу
IP адрес источника - 80.0.0.9
IP адрес назначения - 1.1.1.1
NHOP через туннель - 40.0.0.23
От сервера к клиенту
IP адрес источника - 1.1.1.1
IP адрес назначения - 80.0.0.9
Тип инкапсуляции - Plain IP4
R1
30. Google и Facebook
Что используют Google и Facebook?
Как обслужить миллиард пользователей и отдать терабит трафика
Facebook - что известно?
В 2012 году полностью отказались от аппаратных балансировщиков трафика и
перешли на программные варианты (проект shiv), которые функционируют на x86-
серверах. За основу был взят Linux-модуль IPVS (Linux Virtual Server), который
управляется через netlink (Python скрипты, Thrift и т.д.).
Источник - EuroPython 2016, Emmanuel Bretelle, Facebook
1
Google - что известно?
В 2008 году компания начинает активно использовать собственный программный
балансировщик, который получил название Maglev. Maglev активно используется в облаке
Google Cloud Engine. Решение не предполагает интеграцию с Linux Kernel и, скорее всего,
является User Space-реализацией (аналогично Intel DPDK).
Источник - USENIX - Networked Systems Design and Implementation,
Google Maglev - A Fast and Reliable Software Network Load Balancer
2
32. Взаимодействие между пользователем и сервисом
Как происходит взаимодействие между пользователем и сервисом на примере веб-сайтов
Как обслужить миллиард пользователей и отдать терабит трафика
www
A 1.1.1.1
RPS = Request Per SecondUser DNS
GET /
PHP
www
<html> …
Мало RPS
Как получить больше RPS ?
IP 1.1.1.1
33. Как получить больше RPS?
Добавить балансировщик…
Как обслужить миллиард пользователей и отдать терабит трафика
www
A 1.1.1.1
RPS = Request Per SecondUser DNS
GET /
<html> …
Как получить еще больше RPS и полосы пропускания?
L7LB Proxy
IP 1.1.1.1
Мало RPS
PHP
PHP
PHPnginx, proxygen etc.
GET /
<html> …
Больше RPS
34. GET /
<html> …<html> …
Как получить больше RPS?
Добавить балансировщик…
Как обслужить миллиард пользователей и отдать терабит трафика
www
A 1.1.1.1
RPS = Request Per SecondUser DNS
Как получить еще больше RPS и полосы пропускания?
L7LB Proxy
IP 1.1.1.1
Мало RPS
PHP
PHP
PHP
nginx, proxygen etc.
GET /
Больше RPS
L7LB Proxy
L4LB IPVS
IP 1.1.1.1
Linux IPVS
Сеть
L3 DSR - Anycast IP 1.1.1.1
PHP
PHP
PHP
35. GET /
<html> …<html> …
Как получить больше RPS?
Добавить балансировщик…
Как обслужить миллиард пользователей и отдать терабит трафика
www
A 1.1.1.1
RPS = Request Per SecondUser DNS
L7LB Proxy
IP 1.1.1.1
Мало RPS
PHP
PHP
PHP
GET /
L7LB Proxy
nginx, proxygen etc.
Больше RPS
L7LB Proxy
L4LB IPVS
IP 1.1.1.1
L3 DSR - Anycast IP 1.1.1.1
PHP
PHP
PHP
Linux IPVS
Сеть
L4LB IPVS
ECMP
Маршрутизаторы
Сеть
L3/L3-L4 L4 L7
36. Front end кластер
Вид сверху…
Как обслужить миллиард пользователей и отдать терабит трафика
Сеть Дата Центра
Десятки
Сотни
Тысячи
38. GET /
<html> …<html> …
Не хватает RPS?
Просто добавь еще один кластер…
Как обслужить миллиард пользователей и отдать терабит трафика
www
A 1.1.1.1
RPS = Request Per SecondUser DNS LB
L7LB Proxy
IP 1.1.1.1
Мало RPS
PHP
PHP
PHP
nginx, proxygen etc.
GET /
Больше RPS
L7LB Proxy
L7LB Proxy
L4LB IPVS
IP 1.1.1.1
Linux IPVS
Сеть
ECMP
Маршрутизаторы
Сеть
L3 DSR - Anycast IP 1.1.1.1
GET /
<html> … <html> …
L7LB Proxy
IP 2.2.2.2
Мало RPS
PHP
PHP
PHP
nginx, proxygen etc.
GET /
Больше RPS
L7LB Proxy
L7LB Proxy
L4LB IPVS
IP 2.2.2.2
Linux IPVS
Сеть
ECMP
Маршрутизаторы
Сеть
L3 DSR - Anycast IP 2.2.2.2
39. Все еще не хватает RPS?
Просто добавь еще один дата-центр…
Как обслужить миллиард пользователей и отдать терабит трафика
www
A 1.1.1.1
User DNS LB
PHP
PHP
PHP
L7LB Proxy
L7LB Proxy
L7LB Proxy
L4LB IPVSECMP
PHP
PHP
PHP
L7LB Proxy
L7LB Proxy
L7LB Proxy
L4LB IPVSECMP
Дата Центр А
PHP
PHP
PHP
L7LB Proxy
L7LB Proxy
L7LB Proxy
L4LB IPVSECMP
PHP
PHP
PHP
L7LB Proxy
L7LB Proxy
L7LB Proxy
L4LB IPVSECMP
Дата Центр Б
41. Подключение без CDN
Идентифицируем узкие места
Как обслужить миллиард пользователей и отдать терабит трафика
Браузер
(Клиент)
Центр Обработки Данных
(Сервер)
Время подключения
Итого = 2000 ms
250 ms
Обработка запроса
на стороне сервера500 ms
FTB
(первый байт)
+
Время на загрузку
страницы
5 RTT = 5x250 ms = 1250 ms
3-5 RTT
42. Подключение через Edge-узлы
Content Delivery Network
Как обслужить миллиард пользователей и отдать терабит трафика
Браузер
(Клиент)
Центр Обработки Данных
(Сервер)
CDN
(Edge узел)
Задержка 100ms
Задержка 250ms
«Прогретое»
TCP-подключение
43. Подключение через Edge-узлы
Content Delivery Network
Как обслужить миллиард пользователей и отдать терабит трафика
Браузер
(Клиент)
Центр Обработки Данных
(Сервер)
CDN
(Edge узел)
«Прогретое»
TCP-подключение
100 ms
Время подключения
Обработка запроса
на стороне сервера500 ms
1xRTT
FTB
(первый байт)
+
Время на загрузку
страницы
5 RTT = 5x100 ms = 500 ms
Итого = 1100 ms
Экономия = 900 ms
Оптимизированное
TCP-окно
44. Как пользователь попадает на нужный узел?
Выбор оптимального узла
Как обслужить миллиард пользователей и отдать терабит трафика
GSLB - DNS Mapping
Global Server Load Balancing с использованием DNS-серверов. DNS возвращает
пользователю информацию об IP-адресе ближайшего CDN-узла на основе
географического местоположения пользователя. Иначе говоря, mapping
выполняется на уровне DNS с использованием GeoIP-информации. Отдельные узлы
могут быть уязвимы к DDoS-атакам.
Кто использует - Akamai Technologies, Facebook
1
Global Anycast - маршрутизация к ближайшему
DNS-сервера всегда возвращают один и тот же IP-адрес (либо используется Round-Robin-
механизм). Пользователь, автоматически маршрутизируется к ближайшему CDN-узлу на основе
маршрутной информации операторов связи (BGP). Технология Anycast позволяет абсорбировать
Volume metric DDoS-атаки (более 1Tbps).
Кто использует - CloudFlare, Qrator, Fastly
2
45. GSLB - DNS Mapping
Выбор оптимального узла
Как обслужить миллиард пользователей и отдать терабит трафика
Cartographer
GeoIP DataBase
www ?
www ?
www ?
www ?
www ?
www ?
DNS
B
A
C
D
U
U
U
U
U
U
46. GSLB - DNS Mapping
Выбор оптимального узла
Как обслужить миллиард пользователей и отдать терабит трафика
Cartographer
GeoIP DataBase
DNS
B
A
C
D
A
A
B
C
C
D
U
U
U
U
U
U
47. GSLB - DNS Mapping
Потенциальные проблемы и нюансы
Как обслужить миллиард пользователей и отдать терабит трафика
GeoIP
Балансировка осуществляется от DNS-сервера. Оптимальное распределение
подключений во многом зависит от качества данных в базе GeoIP. Интернет имеет
свойство меняться, требуется поддерживать данную БД в актуальном состоянии.1
Кэширование DNS-запросов
Существует целый ряд особенностей, которые могут быть связаны с кэшированием DNS-ответов
на промежуточных узлах (например DNS-сервера операторов связи) и пользовательских
устройствах. Возникают вопросы с точки зрения надежности и отказоустойчивости.2
48. Кэширование DNS-запросов - MTTR
Пример DNS-ответа - www.facebook.com
Как обслужить миллиард пользователей и отдать терабит трафика
root@localhost# dig +recurse +ttlid +qr +all www.facebook.com
; <<>> DiG 9.9.7-P3 <<>> +recurse +ttlid +qr +all www.facebook.com
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27690
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.facebook.com. IN A
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27690
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.facebook.com. IN A
;; ANSWER SECTION:
www.facebook.com. 2621 IN CNAME star-mini.c10r.facebook.com.
star-mini.c10r.facebook.com. 25 IN A 31.13.72.36
;; Query time: 2 msec
;; SERVER: 172.16.1.1#53(172.16.1.1)
;; WHEN: Sun Oct 15 16:18:41 MSK 2017
;; MSG SIZE rcvd: 79
49. ISP A ISP B ISP C ISP D
Tier 3 - ISP
RTMTT VirginBTTier 2 - ISP
Global Anycast - Как устроен пиринг
Архитектура пиринга в глобальной сети Интернет
Как обслужить миллиард пользователей и отдать терабит трафика
VerizonSprint
Tier 1 - ISP
Telia
Level3
AT&T
Sprint
50. Edge Pop A
Global Anycast - вопросы пиринга
На что следует обратить внимание?
Как обслужить миллиард пользователей и отдать терабит трафика
1.1.1.0/24
Edge Pop B
1.1.1.0/24
Tier 3 Tier 3
Tier 2AS #1 AS #2
AS #3 AS #4 AS #5
Очень важно, с кем мы будем пириться
Это будет оказывать прямое влияние на оптимальное распределение нагрузки
между узлами. Стабильность Global Anycast во многом зависит от стабильности
пира. Возможность влияние на политику маршрутизации транзитного трафика.
Приоритет - Tier 2.1 Tier 2
Tier 3
QRator Labs - BGP Anycast - просто о сложном
NANOG 59 - Renesys - Who Are the Anycasters?
2
Присутствие в конкретном регионе
Больше точек присутствия в конкретном регионе - больше трафика, больше
пользователей, лучше балансировка. Позволяет сегментировать регион
обслуживания. Сегментация доменов отказа - маленький failure rate в глобальном
масштабе.
51. Global Anycast
Влияние радиуса «поражения» на стабильность Global Anycast
Как обслужить миллиард пользователей и отдать терабит трафика
52. Global Anycast
Влияние радиуса «поражения» на стабильность Global Anycast
Как обслужить миллиард пользователей и отдать терабит трафика
Чем больше точек присутствия и пиринга, тем меньше радиус «поражения»
53. Global Anycast - как насчет реальных данных?
Длинные сессии и реальность
Как обслужить миллиард пользователей и отдать терабит трафика
Подключения
Время
Статистика
Итого подключений: 683,204
Подключений длительностью более 10 минут: 23,795
Перемаршрутизаций между Edge-узлами: 4
Статистика Failure Rates (Edge-узел):
Общий показатель: 0.0006 %
Длинные сессии: 0.017%
Источник
TCP Anycast - Don’t believe the FUD, Operational experience
with TCP and Anycast. CacheNetworks, BitGravity, Renesys
54. DNS Mapping vs Global Anycast
Оптимальное распределение подключений
Как обслужить миллиард пользователей и отдать терабит трафика
Регион/Страна
DNS Mapping
Процент оптимального распределения
Global Anycast
Процент оптимального распределения
Иллинойс 70% 90%
Флорида 73% 95%
Джорджия 75% 93%
Пенсильвания 85% 95%
Нью-Йорк 77% 74%
Аризона 60% 39%
Бразилия 88% 33%
70% 90%
73% 95%
75% 93%
85% 95%
77% 74%
60% 39%
88% 33%
Подробнее - http://blog.catchpoint.com/2015/09/24/tcp-over-ip-anycast/
Реальный опыт - LinkedIn
55. Global Anycast
Подводные камни
Как обслужить миллиард пользователей и отдать терабит трафика
R6
IP: 10.0.0.254 IP: 80.0.0.1U1
R2
R5
S1R4
R3
R1
R7
Меньше переходов != маленькая задержка
Большой RTT на маршруте R1-R2-R3-R4
Маленький RTT на маршруте R1-R7-R6-R5-R4