По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Десятая часть тут.
Вы входите в комнату и кричите: «Игорь!» Ваш коллега Игорь оборачивается и начинает разговор о будущем IT-индустрии. Эта способность использовать один носитель (воздух, по которому движется ваш голос) для обращения к одному человеку, даже если многие другие люди используют этот же носитель для других разговоров в одно и то же время, в сетевой инженерии называется мультиплексированием. Более формально:
Мультиплексирование используется, чтобы позволить нескольким объектам, подключенным к сети, обмениваться данными через общую сеть.
Почему здесь используется слово объекты, а не хосты? Возвращаясь к примеру «разговор с Игорем", представьте себе, что единственный способ общения с Игорем — это общение с его ребенком-подростком, который только пишет (никогда не говорит). На самом деле Игорь-член семьи из нескольких сотен или нескольких тысяч человек, и все коммуникации для всей этой семьи должны проходить через этого одного подростка, и каждый человек в семье имеет несколько разговоров, идущих одновременно, иногда на разные темы с одним и тем же человеком. Бедный подросток должен писать очень быстро, и держать много информации в голове, например: "Игорь имеет четыре разговора с Леной", и должен держать информацию в каждом разговоре совершенно отдельно друг от друга. Это ближе к тому, как на самом деле работает сетевое мультиплексирование- рассмотрим:
К одной сети могут быть подключены миллионы (или миллиарды) хостов, и все они используют одну и ту же физическую сеть для связи друг с другом.
Каждый из этих хостов на самом деле содержит много приложений, возможно, несколько сотен, каждое из которых может связываться с любым из сотен приложений на любом другом хосте, подключенном к сети.
Каждое из этих приложений может фактически иметь несколько разговоров с любым другим приложением, запущенным на любом другом хосте в сети.
Если это начинает казаться сложным, то это потому, что так оно и есть. Вопрос, на который должен ответить эта лекция, заключается в следующем:
Как эффективно мультиплексировать хосты через компьютерную сеть?
Далее рассматриваются наиболее часто используемые решения в этом пространстве, а также некоторые интересные проблемы, связанные с этой основной проблемой, такие как multicast и anycast.
Адресация устройств и приложений
Компьютерные сети используют ряд иерархически расположенных адресов для решения этих проблем. Рисунок 1 иллюстрирует это. На рисунке 1 показаны четыре уровня адресации:
На уровне физического канала существуют адреса интерфейсов, которые позволяют двум устройствам обращаться к конкретному устройству индивидуально.
На уровне хоста существуют адреса хостов, которые позволяют двум хостам напрямую обращаться к конкретному хосту.
На уровне процесса существуют номера портов, которые в сочетании с адресом хоста позволяют двум процессам обращаться к конкретному процессу на конкретном устройстве.
На уровне диалога (разговора) набор порта источника, порта назначения, адреса источника и адреса назначения может быть объединен, чтобы однозначно идентифицировать конкретный разговор или поток.
Эта схема и объяснение кажутся очень простыми. В реальной жизни все гораздо запутаннее. В наиболее широко развернутой схеме адресации - интернет-протоколе IP отсутствуют адреса уровня хоста. Вместо этого существуют логические и физические адреса на основе каждого интерфейса.
Идентификаторы (адреса) мультиплексирования и мультиплексирование иерархически расположены друг над другом в сети.
Однако есть некоторые ситуации, в которых вы хотите отправить трафик более чем на один хост одновременно. Для этих ситуаций существуют multicast и anycast. Эти два специальных вида адресации будут рассмотрены в следующих лекциях.
О физических каналах, Broadcasts, и Failure Domains
Простая модель, показанная на рисунке 1, становится более сложной, если принять во внимание концепцию широковещательных доменов и физического подключения. Некоторые типы мультимедиа (в частности, Ethernet) разработаны таким образом, что каждое устройство, подключенное к одной и той же физической линии связи, получает каждый пакет, передаваемый на физический носитель—хосты просто игнорируют пакеты, не адресованные одному из адресов, связанных с физическим интерфейсом, подключенным к физическому проводу. В современных сетях, однако, физическая проводка Ethernet редко позволяет каждому устройству принимать пакеты любого другого устройства. Вместо этого в центре сети есть коммутатор, который блокирует передачу пакетов, не предназначенных для конкретного устройства, по физическому проводу, подключенному к этому хосту.
В этих протоколах, однако, есть явные адреса, отведенные для пакетов, которые должны передаваться каждому хосту, который обычно получал бы каждый пакет, если бы не было коммутатора, или что каждый хост должен был получать и обрабатывать (обычно это некоторая форма версия адреса все 1 или все 0). Это называется трансляцией (broadcasts). Любое устройство, которое будет принимать и обрабатывать широковещательную рассылку, отправленную устройством, называется частью широковещательной рассылки устройства. Концепция широковещательного домена традиционно тесно связана с областью сбоев, поскольку сбои в сети, влияющие на одно устройство в широковещательном домене, часто влияют на каждое устройство в широковещательном домене.
Не удивляйтесь, если вы найдете все это довольно запутанным, потому что на самом деле это довольно запутанно. Основные понятия широковещания и широковещательных доменов все еще существуют и по-прежнему важны для понимания функционирования сети, но значение этого термина может измениться или даже не применяться в некоторых ситуациях. Будьте осторожны при рассмотрении любой ситуации, чтобы убедиться, что вы действительно понимаете, как, где и, что такие широковещательные домены действительно существуют, и как конкретные технологии влияют на отношения между физической связью, адресацией и широковещательными доменами.
OSPF (Open Shortest Path First) – дословно переводится как «Сперва открытый короткий путь» - надежный протокол внутренней маршрутизации с учетом состояния каналов (Interior gateway protocol, IGP). Как правило, данный протокол маршрутизации начинает использоваться тогда, когда протокола RIP уже не хватает по причине усложнения сети и необходимости в её легком масштабировании.
OSPF наиболее широко используемый протокол внутренней маршрутизации. Когда идёт речь о внутренней маршрутизации, то это означает, что связь между маршрутизаторами устанавливается в одном домене маршрутизации, или в одной автономной системе. Представьте компанию среднего масштаба с несколькими зданиями и различными департаментами, каждое из которых связано с другим с помощью канала связи, которые дублируются с целью увеличения надежности. Все здания являются частью одной автономной системы. Однако при использовании OSPF, появляется понятие «площадка», «зона» (Area), которое позволяет сильнее сегментировать сеть, к примеру, разделение по «зонам» для каждого отдельного департамента.
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Для понимания необходимости данных «зон» при проектировании сети, необходимо понять, как OSPF работает. Есть несколько понятий, связанных с этим протоколом, которые не встречаются в других протоколах и являются уникальными:
Router ID: Уникальный 32-х битный номер, назначенный каждому маршрутизатору. Как правило, это сетевой адрес с интерфейса маршрутизатора, обладающий самым большим значением. Часто для этих целей используется loopback интерфейс маршрутизатора.
Маршрутизаторы-соседи: Два маршрутизатора с каналом связи между ними, могут посылать друг другу сообщения.
Соседство: Двухсторонние отношения между маршрутизаторами-соседями. Соседи не обязательно формируют между собой соседство.
LSA: Link State Advertisement – сообщение о состоянии канала между маршрутизаторами.
Hello сообщения: С помощью этих сообщений маршрутизаторы определяют соседей и формируют LSA
Area (Зона): Некая иерархия, набор маршрутизаторов, которые обмениваются LSA с остальными в одной и той же зоне. Зоны ограничивают LSA и стимулируют агрегацию роутеров.
OSPF – протокол маршрутизации с проверкой состояния каналов. Представьте себе карту сети – для того, чтобы ее сформировать, OSPF совершает следующие действия:
Сперва, когда протокол только запустился на маршрутизаторе, он начинает посылать hello-пакеты для нахождения соседей и выбора DR (designated router, назначенный маршрутизатор). Эти пакеты включают в себя информацию о соседях и состоянии каналов. К примеру, OSPF может определить соединение типа «точка-точка», и после этого в протоколе данное соединение «поднимается», т.е. становится активным. Если же это распределенное соединение, маршрутизатор дожидается выбора DR перед тем как пометить канал активным.
Существует возможность изменить Priority ID для, что позволит быть уверенным в том, что DR-ом станет самый мощный и производительный маршрутизатор. В противном случае, победит маршрутизатор с самым большим IP-адресом. Ключевая идея DR и BDR (Backup DR), заключается в том, что они являются единственными устройствами, генерирующими LSA и они обязаны обмениваться базами данных состояния каналов с другими маршрутизаторами в подсети. Таким образом, все не-DR маршрутизаторы формируют соседство с DR. Весь смысл подобного дизайна в поддержании масштабируемости сети. Очевидно, что единственный способ убедиться в том, что все маршрутизаторы оперируют одной и той же информацией о состоянии сети – синхронизировать БД между ними. В противном случае, если бы в сети было 35 маршрутизаторов, и требовалось бы добавить еще одно устройство, появилась бы необходимость в установлении 35 процессов соседства. Когда база централизована (т.е существует центральный, выбранный маршрутизатор - DR) данный процесс упрощается на несколько порядков.
Обмен базами данных – крайне важная часть процесса по установлению соседства, после того как маршрутизаторы обменялись hello-пакетами. При отсутствии синхронизированных баз данных могут появиться ошибки, такие как петли маршрутизации и т.д. Третья часть установления соседства – обмен LSA. Это понятие будет разобрано в следующей статье, главное, что необходимо знать – нулевая зона (Area 0) особенная, и при наличии нескольких зон, все они должны быть соединены с Area 0. Так же это называется магистральной зоной.
Типы маршрутизаторов OSPF
Разберем различные типы маршрутизаторов при использовании протокола OSPF:
ABR
Area Border Router – маршрутизатор внутри нулевой зоны, через который идет связь с остальными зонами
DR, BDR
Designated Router, Backup Designated Router – этот тип маршрутизаторов обсуждался выше, это основной и резервирующий маршрутизаторы, которые ответственны за базу данных маршрутизаторов в сети. Они получают и посылают обновления через Multicast остальным маршрутизаторам в сети.
ASBR
Autonomous System Boundary Router – этот тип маршрутизаторов соединяет одну или несколько автономных систем для осуществления возможного обмена маршрутами между ними.
Подведем итоги
OSPF является быстро сходящимся протоколом внутренней маршрутизации с контролем состояния каналов
Процесс соседства формируется между соседними маршрутизаторами через DR и BDR, используя LSA
Зоны в данном протоколе маршрутизации используются для ограничения LSA и суммирования маршрутов. Все зоны подключаются к магистральной зоне.
Что это вообще такое?
Docker Compose является инструментом для определения и запуска контейнерных приложений. С Compose вы получаете возможность настраивать службы используя файл YAML. С помощью одной команды Compose вы создаете и запускаете все службы в соответствии с вашей конфигурацией.
Установка начинается с создания каталога проекта:
$ mkdir composetest
$ cd composetest
Создайте файл под названием app.py и вставьте в него следующие данные:
import time
import redis
from flask import Flask
app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)
def get_hit_count():
retries = 5
while True:
try:
return cache.incr('hits')
except redis.exceptions.ConnectionError as exc:
if retries == 0:
raise exc
retries -= 1
time.sleep(0.5)
@app.route('/')
def hello():
count = get_hit_count()
return 'Hello World! I have been seen {} times.
'.format(count)
В нашем случае название хоста - redis, который использует порт 6379. Создайте файл под названием needs.txt в каталоге вашего проекта и вставьте его в:
flask
Redis
Теперь следует написать код для файла Dockerfile, содержащий все необходимые переменные для среды разработки.
В каталоге вашего проекта создайте файл с именем Dockerfile (файл будет определять среду приложения) и вставьте следующее содержимое:
FROM python:3.7-alpine
WORKDIR /code
ENV FLASK_APP app.py
ENV FLASK_RUN_HOST 0.0.0.0
RUN apk add --no-cache gcc musl-dev linux-headers
COPY requirements.txt requirements.txt
RUN pip install -r requirements.txt
COPY . .
CMD ["flask", "run"]
Определение сервисов осуществляется при создании файла с именем docker-compose.yml в каталоге вашего проекта со следующей информацией:
version: '3'
services:
web:
build: .
ports:
- "5000:5000"
redis:
image: "redis:alpine"
На основании содержания файла происходит запуск двух сервисов: Web и Redis, а в дальнейшем вы можете вносить в этот файл различные БД и иную важную информацию.
C помощью команды Compose создайте ваше приложение, после чего из каталога проекта запустите приложение, запустив docker-compose. Вот так:
$ docker-compose up
Creating network "composetest_default" with the default driver
Creating composetest_web_1 ...
Creating composetest_redis_1 ...
Creating composetest_web_1
Creating composetest_redis_1 ... done
Attaching to composetest_web_1, composetest_redis_1
web_1 | * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
redis_1 | 1:C 17 Aug 22:11:10.480 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis_1 | 1:C 17 Aug 22:11:10.480 # Redis version=4.0.1, bits=64, commit=00000000, modified=0, pid=1, just started
redis_1 | 1:C 17 Aug 22:11:10.480 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
web_1 | * Restarting with stat
redis_1 | 1:M 17 Aug 22:11:10.483 * Running mode=standalone, port=6379.
redis_1 | 1:M 17 Aug 22:11:10.483 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
web_1 | * Debugger is active!
redis_1 | 1:M 17 Aug 22:11:10.483 # Server initialized
redis_1 | 1:M 17 Aug 22:11:10.483 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
web_1 | * Debugger PIN: 330-787-903
redis_1 | 1:M 17 Aug 22:11:10.483 * Ready to accept connections
Compose извлекает образ Redis, создавая образ для вашего приложения и запускает выбранные службы. В этом случае код копируется в образ во время сборки. Как вам такое?
Теперь попробуйте ввести http://localhost:5000/ в браузере, чтобы чекнуть запущенное приложение.
Если вы используете Docker для Linux, Docker Desktop для Mac или Docker Desktop для Windows, то теперь веб-приложение должно "смотреть" на порт 5000 на хосте Docker. Введите в своем веб-браузере адрес http://localhost:5000, чтобы увидеть сообщение Hello World. Если не сработает, вы также можете попробовать зайти на http://127.0.0.1:5000.
Если вы используете Docker Machine на Mac или Windows, используйте ip MACHINE_VM docker-machine для получения IP-адреса вашего хоста Docker. Затем откройте http://MACHINE_VM_IP:5000 в браузере.
Вы должны увидеть сообщение в своем браузере:
Hello World! I have been seen 1 times.
Переключитесь на другое окно терминала и введите docker image ls, чтобы вывести список локальных образов/контейнеров. Вывод на этом этапе должен показывать redis и web.
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
composetest_web latest e2c21aa48cc1 4 minutes ago 93.8MB
python 3.4-alpine 84e6077c7ab6 7 days ago 82.5MB
redis alpine 9d8fa9aa0e5b 3 weeks ago 27.5MB
Важно: Вы можете просматривать запущенные контейнеры с помощью Docker Inspect Tag или ID
Запустите docker-compose из каталога вашего проекта во втором терминале, либо нажмите CTRL + C в исходном терминале, где приложение уже запущено и отредактируйте файл Compose.
Отредактируйте docker-compose.yml в каталоге вашего проекта для внесения той или иной правки в веб-службе
version: '3'
services:
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/code
environment:
FLASK_ENV: development
redis:
image: "redis:alpine"
Новый ключ редактирует каталог проекта на хосте внутри контейнера, что позволяет изменять код без необходимости перестраивать весь образ. Ключ среды устанавливает переменную FLASK_ENV, которая сообщает о запуске в режиме разработки и перезагрузке кода при изменении. Важно: этот режим должен использоваться только при разработке.
В каталоге проекта введите docker-compose up, чтобы создать приложение с обновленным файлом Compose, и запустите его.
$ docker-compose up
Creating network "composetest_default" with the default driver
Creating composetest_web_1 ...
Creating composetest_redis_1 ...
Creating composetest_web_1
Creating composetest_redis_1 ... done
Attaching to composetest_web_1, composetest_redis_1
web_1 | * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
…
Поскольку код приложения теперь добавляется в контейнер с помощью тома, вы можете вносить изменения в его код и мгновенно просматривать изменения без необходимости перестраивать образ.
Измените сообщение в app.py и сохраните его:
Hello from Docker!:
return 'Hello from Docker! I have been seen {} times.
'.format(count)
Обновите результат в вашем браузере (нажмите F5 или Ctrl + F5) . Приветствие должно быть обновлено, а счетчик должен увеличиваться.
Вы можете поэкспериментировать с другими командами. Если вы хотите запускать свои службы в фоновом режиме, вы можете сделать следующее:
docker-compose up and use docker-compose ps to see what is currently running:
$ docker-compose up -d
Starting composetest_redis_1...
Starting composetest_web_1...
$ docker-compose ps
Name Command State Ports
-------------------------------------------------------------------
composetest_redis_1 /usr/local/bin/run Up
composetest_web_1 /bin/sh -c python app.py Up 5000->5000/tcp
Команда docker-compose run позволяет вам применять одноразовые команды к вашим сервисов. Например, чтобы увидеть, какие переменные среды доступны для веб-службы:
$ docker-compose run web env
Выполните команду docker-compose –help, чтобы увидеть весь список доступных команд.
Если вы запустили Compose с помощью docker-compose up -d, то нужно будет остановить ваши службы после работы с ними, для этого поможет команда ниже:$ docker-compose stop
Если хотите полностью уничтожить контейнер, используйте команду down.