Как обслужить миллиард пользователей и отдать терабит трафика

Как обслужить миллиард пользователей и отдать
терабит трафика
ПАО Сбербанк России, Руководитель направления,
Отдел телекоммуникационной инфраструктуры Дата-Центров
Igor Vasiliev, CCIE No.: 19895
Электронная почта: iivasiliev@gmail.com

Краткий обзор

Тема данной презентации
Как обслужить миллиард пользователей и отдать терабит трафика
Основы балансировки
Такие сервисы, как Google, Facebook, Twitter, NetFlix, Linkedin и т.д. и т.п.,
применяют многоуровневые механизмы балансировки, которые
не ограничиваются конкретным уровнем модели OSI.1
Архитектура популярных Интернет-сервисов
Большинство Интернет-сервисов существует в пределах нескольких Центров
Обработки Данных, которые разбросаны по всему миру и представляют
собой распределенную архитектуру.2
CDN и Edge-узлы
Инфраструктура популярных Интернет-сервисов не ограничивается ЦОД, а так
называемые «Edge» узлы формируют некоторое подобие CDN-сети, которая
обеспечивает оптимальное распределение подключений.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 процессоров
«В случае, когда задача разделяется на несколько частей, суммарное время её
выполнения на параллельной системе не может быть меньше времени выполнения
самого длинного фрагмента.»

Ultimate question of life the universe and everything

Anycast

Как работает 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!

Как работает 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)

Основная проблема

TCP Reset и Session Persistance
Host
Host
Host
Router
SYN
SYN/ACK
ACK
RST
TCP Reset

ECMP-балансировка и
методы хэширования

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


Реализация в телекоммуникационном оборудовании
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

Хэш-функция

Алгоритмы балансировки
Варианты балансировки
Существует два режима балансировки: per-packet и per-flow. Режим per-packet не
рекомендуется использовать, так как это может приводить к проблемам с TCP Out-Of-
Order и TCP Reset (обрыв подключения).1
Хэширующая функция
Представляет собой математическую операцию, которая основывается на таких
алгоритмах, как XOR или CRC. В некоторых случаях может использовать битовое
смещение. Влияет на распределение трафика. Результат хэш-функции предсказуем и не
изменчив.
2
Особенности реализаций
Некоторые устройства могут использовать дополнительные параметры (соль), которые
подмешиваются в математическую функцию алгоритма хэширования. Например,
устройства под управлением ОС Cisco IOS XR используют Router ID. Помогает бороться
с эффектом поляризации FIB.
3

Традиционный подход

Стандартный способ распределения ключей в хэш таблице
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

Консистентное хэширование

Рекурсивное распределение ключей
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

Эффект поляризации 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
Нет трафика
Нет трафика


Топология Клоза и эффект поляризации FIB
R3
R8
R1
R5R4
R2
R7
R6
R9

RACKA

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

RACKA

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

RACKA

IP: 1.1.1.1
IP: 10.0.0.1
R3
IP: 10.0.0.254
U1
R8
S2
RACKB
R1R1
R5R4
R2
TCP Reset
IP: 1.1.1.1
IP: 10.0.0.2
R7
R6
S1
R9

RACKA

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).

TCP SYN Proxy

Асимметричная маршрутизация

Основные принципы маршрутизации трафика
U
R2
S via R2
S via R3
S direct connected
SR1 R3
U via R1U direct connected

Традиционный подход - 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
От балансировщика к серверу
MAC адрес назначения - BBBBB2
От сервера к клиенту
MAC адрес назначения - Шлюз по-умолчанию3
1
2
3
Потенциальные проблемы
Масштабируемость L2 сегментов
Broadcast flooding
L2 DCI и растянутые L2 сегменты
Неэффективная утилизация каналов связи (STP-блокировка
резервных подключений) и т.д. и т.п.
…
R1

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
От клиента к балансировщику
Тип инкапсуляции - Plain IP1
Туннель между балансировщиком и сервером
Тип инкапсуляции - IPIP/GRE Tunnel2
От балансировщика к серверу
NHOP через туннель - 40.0.0.23
От сервера к клиенту
Тип инкапсуляции - Plain IP4
R1

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

Facebook

Взаимодействие между пользователем и сервисом

Как происходит взаимодействие между пользователем и сервисом на примере веб-сайтов
www
A 1.1.1.1
RPS = Request Per SecondUser DNS
GET /
PHP
www
<html> …
Мало RPS
Как получить больше RPS ?
IP 1.1.1.1

Как получить больше RPS?

Добавить балансировщик…
www
A 1.1.1.1
GET /
<html> …
Как получить еще больше RPS и полосы пропускания?
L7LB Proxy
IP 1.1.1.1
Мало RPS
PHP
PHP
PHPnginx, proxygen etc.
GET /
<html> …
Больше RPS

GET /
<html> …<html> …

www
A 1.1.1.1
Как получить еще больше 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

GET /

www
A 1.1.1.1
L7LB Proxy
IP 1.1.1.1
Мало RPS
PHP
PHP
PHP
GET /
L7LB Proxy
Больше RPS
L7LB Proxy
L4LB IPVS
IP 1.1.1.1
PHP
PHP
PHP
Linux IPVS
Сеть
L4LB IPVS
ECMP
Маршрутизаторы
Сеть
L3/L3-L4 L4 L7

Front end кластер

Вид сверху…
Сеть Дата Центра
Десятки
Сотни
Тысячи

Десятки тысяч

GET /
Не хватает RPS?

Просто добавь еще один кластер…
www
A 1.1.1.1
RPS = Request Per SecondUser DNS LB
L7LB Proxy
IP 1.1.1.1
Мало RPS
PHP
PHP
PHP
GET /
Больше RPS
L7LB Proxy
L7LB Proxy
L4LB IPVS
IP 1.1.1.1
Linux IPVS
Сеть
ECMP
Сеть
GET /
<html> … <html> …
L7LB Proxy
IP 2.2.2.2
Мало RPS
PHP
PHP
PHP
GET /
Больше RPS
L7LB Proxy
L7LB Proxy
L4LB IPVS
IP 2.2.2.2
Linux IPVS
Сеть
ECMP
Сеть

Все еще не хватает 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
Дата Центр Б

Content Delivery Networks

Подключение без CDN

Идентифицируем узкие места
Браузер
(Клиент)
Центр Обработки Данных
(Сервер)
Время подключения
Итого = 2000 ms
250 ms
Обработка запроса
на стороне сервера500 ms
FTB
(первый байт) 
+
Время на загрузку
страницы
5 RTT = 5x250 ms = 1250 ms
3-5 RTT

Подключение через Edge-узлы

Content Delivery Network
Браузер
(Клиент)
(Сервер)
CDN 
(Edge узел)
Задержка 100ms
Задержка 250ms
«Прогретое»
TCP-подключение

Подключение через Edge-узлы

Content Delivery Network
Браузер
(Клиент)
(Сервер)
CDN 
(Edge узел)
«Прогретое»
TCP-подключение
100 ms
Время подключения
Обработка запроса
на стороне сервера500 ms
1xRTT
FTB
(первый байт) 
+
Время на загрузку
страницы
5 RTT = 5x100 ms = 500 ms
Итого = 1100 ms
Экономия = 900 ms
Оптимизированное
TCP-окно

Как пользователь попадает на нужный узел?

Выбор оптимального узла
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

GSLB - DNS Mapping

Cartographer
GeoIP DataBase
www ?
www ?
www ?
www ?
www ?
www ?
DNS
B
A
C
D
U
U
U
U
U
U

GSLB - DNS Mapping

Cartographer
GeoIP DataBase
DNS
B
A
C
D
A
A
B
C
C
D
U
U
U
U
U
U

GSLB - DNS Mapping

Потенциальные проблемы и нюансы
GeoIP
Балансировка осуществляется от DNS-сервера. Оптимальное распределение
подключений во многом зависит от качества данных в базе GeoIP. Интернет имеет
свойство меняться, требуется поддерживать данную БД в актуальном состоянии.1
Кэширование DNS-запросов
Существует целый ряд особенностей, которые могут быть связаны с кэшированием DNS-ответов
на промежуточных узлах (например DNS-сервера операторов связи) и пользовательских
устройствах. Возникают вопросы с точки зрения надежности и отказоустойчивости.2

Кэширование 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

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

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 в глобальном
масштабе.

Global Anycast

Влияние радиуса «поражения» на стабильность Global Anycast

Global Anycast

Влияние радиуса «поражения» на стабильность Global Anycast
Чем больше точек присутствия и пиринга, тем меньше радиус «поражения»

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

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

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

Вопросы?

Как обслужить миллиард пользователей и отдать терабит трафика

Recommended

Recommended

More Related Content

Similar to Как обслужить миллиард пользователей и отдать терабит трафика

Similar to Как обслужить миллиард пользователей и отдать терабит трафика (20)

Как обслужить миллиард пользователей и отдать терабит трафика