По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Перед тем как говорить о технологии 802.1ad (QinQ) нужно вспомнить о технологии 802.1q. Если коротко, то это технология тегирования трафика, то есть деление его на 2 уровне модели OSI (так как на L3 сеть мы делим уже по маске)
Чем же отличается трафик обычный от тегированного спросите вы? Практически ничем, кроме добавления добавление тега в заголовок фрейма.
Размер такого тега всего 4 байта (32 бита) и он состоит:
TPID (Tag Protocol Identifier): на него уходит половина размера тега и это значение равно 0x8100 для 802.1q (VLAN) , а для 802.1ad(QinQ) заголовок выглядит так: 0x88a8.
TCI (Tag Control Information): на это поле уходит оставшийся половина 16 бит тега.
В него входит:
PCP(Priority) - 3-битное поле, которое относится к классу обслуживания IEEE 802.1p и сопоставляется с уровнем приоритета кадра. (3 бита)
Drop eligible indicator (DEI) (ранее CFI - Canonical Format Indicator) - Может использоваться отдельно или вместе с PCP для обозначения фреймов, которые могут быть отброшены при наличии перегрузки. (1 бит )
VID (VLAN Identifier) - VLAN ID . размером он в 12 бит ,а это значит что в него можно заложить 2^12 = 4096 VLAN . Но на самом деле меньше ,так как 0 и 4095( 0x000 и 0xFFF) зарезервированы , в итоге 4094 получается. (12 бит)
Зачем же понадобилась технология двойного тегирования QinQ? Вот тут возникает как раз ограничение поля VID на количество VLAN (4094) и тут на помощь приходит стандарт 802.1ad, который позволяет уже увеличить количество VLAN. (4094*4094 = 16760836 - больше пока никому не потребовалось.)
Ниже укажу dump трафика вначале обычного 802.1q:
А потом 802.1ad наш QinQ о котором как раз и шла речь:
Как видно из вывода, тип трафика указывается в самом фрейме. (см картинки выше), а далее идёт тег и в случае QinQ ещё один тег.
Практика
А теперь давайте немного попрактикуемся.
Клиенты VPC1 и VPC2 будут находиться в одной подсети, это было сделано для удобства.
VPC1 : 172.16.20.1/24
VPC2 : 172.16.20.2/24
Теперь первый Mikrotik, который будет отвечать за access и trunk порты
/interface bridge
add name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1 pvid=100
add bridge=bridge interface=ether2
/interface bridge vlan
add bridge=bridge tagged=ether2 vlan-ids=100
Mikrotik4 конфигурируется точно по такой же логике
/interface bridge
add name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1 pvid=100
add bridge=bridge interface=ether2
/interface bridge vlan
add bridge=bridge tagged=ether2 vlan-ids=100
Теперь самое интересное: Mikrotik2
/interface bridge
add ether-type=0x88a8 name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1 pvid=200 tag-stacking=yes
add bridge=bridge interface=ether2
/interface bridge vlan
add bridge=bridge tagged=ether1 vlan-ids=100
add bridge=bridge tagged=ether2 vlan-ids=200
Mikrotik3
/interface bridge
add ether-type=0x88a8 name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2 pvid=200 tag-stacking=yes
/interface bridge vlan
add bridge=bridge tagged=ether2 vlan-ids=100
add bridge=bridge tagged=ether1 vlan-ids=200
Я указал только простую настройку для понимания настройки его на оборудовании Mikrotik. Не стал копать глубоко и указывать что и зачем каждый заголовок значит, так как моей задачей было указать основную настройку оборудования и по какой логике работает Q-in-Q, и с этой задачей я справился. Удачи!
Представьте ситуацию, пользователи пытаются получить доступ к вашему сайту, но он не открывается. Знаете в чём дело? Возможно, есть ошибки, которые не были выявлены и решены раньше. Разочарованные пользователи покидают ваш сайт, а вы теряете лояльных пользователей.
Как решить эту проблему? Как узнать о состоянии сайта раньше пользователей?
Существует два возможных способа - eсли вы не против потратить немного денег, то можно обратиться к таким мониторинговым решениям, как StartCake и т.п. Однако если вы разработчик или не готовы тратиться ежемесячно, можете воспользоваться преимуществами API Geekflare - Site Up?
Данный API проверяет доступность сайта из разных точек.
В данном материале рассмотрим Python код, который немедленно уведомит вас через Gmail, как только сайт станет недоступен. Начнем с изучения API «Is Site Up?»
API Is Site Up?
Перед началом работы с API необходимо установить пакет requests, который в Python используется для работы с API. Но не обязательно использовать Python. Можно использовать любой другой язык. В любом случае, убедитесь, что настроили все необходимое, чтобы сделать API запрос.
Итак, для тех, кто использует Python, установите пакет запросов с помощью команды:
pip install requests
Выполните настройку для других языков (если выбран другой язык, кроме Python) и переходите к следующим шагам.
Теперь перейдите на страницу API Geekflare.
Вы можете найти различные типы API, включая «Is Site Up?». Для использования API Geekflare нам нужен ключ API, который мы можем получить через RapidAPI.
Нажмите на кнопку GET API KEY, чтобы перейти к RapidAPI.
RapidAPI откроется в новой вкладке и выглядит следующим образом:
Чтобы получить ключ API нужно создать учетную запись. Создайте учетную запись в RapidAPI, если у вас ее нет.
Затем в верхней части всех доступных API Geekflare вы увидите API «Is Site Up?», который мы ищем. Если он не активен, найдите его с помощью поиска и нажмите на него. После этого в правой стороне должно отобразиться руководство по данному API. Из раздела Code Snippets в правой части выберите Python -> Requests.
Или же если вы не используете Python, выберите другой язык с соответствующим пакетом.
Вы получите код для вызова API «Is Site Up?». Давайте изменим его немного, чтобы потом легче было добавлять код. Посмотрите на измененный код в Python.
import requests
API_URL = "https://geekflare.p.rapidapi.com/up"
def make_api_request():
headers = {
'content-type': "application/json",
'x-rapidapi-host': "geekflare.p.rapidapi.com",
'x-rapidapi-key': "YOUR_API_KEY"
}
payload = r'{"url": "https://www.geekflare.com"}'
response = requests.request("POST", API_URL, data=payload, headers=headers)
return response.json()
if __name__ == '__main__':
data = make_api_request()
print(data)
Замените API_KEY своим собственным ключом API из RapidAPI в приведенном выше коде. Он будет разным для каждого пользователя. Вы найдете его в RapidAPI в разделе Параметры заголовка:
Тот же ключ API вы сможете найти в примере кода, как показано ниже.
Несколько расположений
В приведенном выше коде сайт проверяется из одного датацентра (Нью-Йорк, США). Но мы можем посылать запросы на сайт из разных мест с указав буквенные коды стран в теле запроса. Другие доступные места - Англия (Лондон) и Сингапур. Мы можем передать данные местоположения вместе с URL-адресом сайта следующим образом:
{
"locations": [
"uk",
"us",
"sg"
],
"url": "geekflare.com"
}
Вы можете передать предпочитаемые расположения из списка.
Мы написали код, чтобы сделать запрос API, который получает данные независимо от того, работает сайт или нет. Пришло время написать еще код, который отправляет почту, когда сайт не работает.
Получение уведомления на почту
В сети можно найти немало руководств о том, как отправлять электронные письма через Gmail в Python или же использовать следующий код, который использует пакет под названием yagmail специально разработан для отправки почты из Gmail.
Перед отправкой сообщения через учетную запись Gmail необходимо включить параметр Разрешить небезопасные приложения. Вы можете включить его здесь. Посмотрим код:
def send_mail():
gmail = yagmail.SMTP("gmail", "password")
receiver = "receiver@domain.com"
subject = "Testing Subject"
body = "This is a testing mail"
gmail.send(
to=receiver,
subject=subject,
contents=body,
)
Полное руководство по yagmail можно найти здесь.
Теперь у нас есть код для запросов API и отправки почты. Следующим шагом является вызов send_mail всякий раз, когда в ответе на запрос сайт указывается как недостпный.
Итак, откуда мы знаем, что наш сайт не работает или работает? Когда мы посылаем запрос к API «Is Site Up?», он возвращает нам Python словарь с некоторыми данными как следующем скриншоте:
В данном словаре есть ключ message. Значение этого ключа и показывает нам состояние сайта. Данный ключ может иметь два значения:
Site is up
Site is down
Итак, мы отправим почту, когда получим сообщение «Site is down». Окончательный код будет выглядеть так:
import requests
import yagmail
API_URL = "https://geekflare.p.rapidapi.com/up"
def make_api_request():
headers = {
'content-type': "application/json",
'x-rapidapi-host': "geekflare.p.rapidapi.com",
'x-rapidapi-key': "API_KEY"
}
payload = r'{"url": "https://www.abcd.com"}'
response = requests.request("POST", API_URL, data=payload, headers=headers)
return response.json()
def send_mail(content):
gmail = yagmail.SMTP("gmail", "password")
receiver = "email@domain.com"
subject = "Your Site is Down"
gmail.send(
to=receiver,
subject=subject,
contents=content,
)
if __name__ == '__main__':
data = make_api_request()
message = data['message']
## seding the mail
if message == 'Site is down.':
## extracting the errors from different locations
locations_data = data['data']
mail_content = "Your site is down due to unexpected error. See the useful data to resolve errors below.
"
for location in locations_data:
mail_content += f"{location['city']}, {location['country']} - {location['error']}
"
mail_content += "
Check the error and resolve them as soon as possible."
send_mail(mail_content)
Тело сообщения можете редактировать по своему усмотрению. Мы завершили код отправки почты всякий раз, когда наш сайт не работает. Смотри образец сообщения, полученного с помощью вышеуказанного кода.
Но, есть еще проблема.
Мы должны выполнить наш код, чтобы проверить, работает ли наш сайт или нет. Частота запуска данного скрипта зависит от ваших предпочтений. Допустим, мы должны проверять сайт каждые час.
Правда, мы можем каждый час открыть терминал и запустить скрипт. Но это скучно и неэффективно. Плюс к этому, никто так не делает. Решение напрашивается само: использовать cron для автоматического выполнения нашего кода каждый час. Посмотрим, как его настроить.
Настройка Cron
Рассмотрим шаги по настройке cron в операционной системе на базе UNIX.
Открыть терминал.
Выполните команду crontab -e, которая открывает файл crontab на терминале.
Нажмите клавишу i для перехода в режим ВВОДА.
Теперь добавьте шаблон cron, пути к исполняемому файлу Python и нашему файлу, как указано ниже:
0 * * * * /usr/bin/python3 /home/sample.py
Подробно про cron можно прочесть в этой статье.
Итак, мы настроили планировщик для ежечасного запуска кода. Если нужно будет указать другое расписание, можно воспользоваться разными утилитами для генерации шаблона расписания для cron.
Пожалуй, теперь все. Мы настроили проверку сайта каждый час и получение уведомления на почту, если сайт станет недоступен.
Заключение
Автоматизация экономит много времени и работает на нас. Можно настроить cron на каком-нибудь облаке, чтобы он постоянно работал, проверял состояние сайта и уведомлял нас при сбое.
Если Вы наконец поняли, что повсюду окружены контейнерами и обнаружили, что они решают массу проблем и имеют много преимуществ:
Контейнеры вездесущи - ОС, версии библиотек, конфигурации, папки и приложения помещаются в контейнер. Вы гарантируете, что та же самая задача, которая была протестирована в QA, достигнет производственной среды с таким же поведением.
Контейнеры упрощены - объем памяти контейнера невелик. Вместо сотен или тысяч мегабайт контейнер будет выделять память только для основного процесса.
Контейнеры быстрые - Вы можете запустить контейнер для начала работы так же быстро, как типичный процесс Linux. Вместо минут можно запустить новый контейнер за несколько секунд.
Тем не менее, многие пользователи по-прежнему относятся к контейнерам так же, как к типичным виртуальным машинам, и забывают про важную характеристику: они одноразовые.
Мантра о контейнерах: “Контейнеры эфемерны”.
Эта характеристика заставляет пользователей поменять свое мышление относительно того, как они должны обращаться с контейнерами и управлять ими; и я объясню, чего НЕ следует делать, чтобы продолжать извлекать наилучшие преимущества контейнеров.
10 вещей, которых следует избегать в Docker контейнерах
Не хранить данные в контейнерах - контейнер может быть остановлен, удален или заменен. Приложение версии 1.0, работающее в контейнере, может быть легко заменено версией 1.1 без какого-либо неблагоприятного воздействия или потери данных. Поэтому, если нужно сохранить данные, сделайте это на диске. В этом случае следует также позаботиться о том, чтобы два контейнера записывали данные на один и тот же диск, что может привести к повреждению. Убедитесь, что приложения могут записывать данные в хранилище объектов.
Не разделять свое приложение на две части - так как некоторые люди видят контейнеры в роли виртуальной машин и поэтому большинство из них склонны думать, что они должны применять свое приложение только в существующих работающих контейнерах. Это может быть справедливо на этапе разработки, на котором Вам необходимо непрерывно разрабатывать и налаживать процесс; но для непрерывной доставки (CD) в QA и производства, Ваше приложение должно быть частью образа. Помните: Контейнеры нельзя изменить.
Не создавать большие образы - большой образ будет труднее распространить. Убедитесь в наличии только необходимых файлов и библиотек для запуска приложения/процесса. Не устанавливайте ненужные пакеты и не запускайте обновления (yum update), которые загружают много файлов на новый слой образы.
Не использовать однослойный образ - чтобы эффективно пользоваться многоуровневой файловой системой, всегда создавайте собственный базовый слой образы для операционной системы, а также другой слой для определения имени пользователя, слой для установки во время выполнения, слой для конфигурации и, наконец, слой для приложения. Будет проще воссоздать образ, управлять им и использовать его.
Не создавать образы из запущенных контейнеров - другими словами, не используйте слово docker commit для создания образа. Этот способ не приносит пользы, и его следует полностью избегать. Всегда используйте полностью воспроизводимый Dockerfile или любой другой S2I (от источника к изображению) подход, и Вы можете отследить изменения в Dockerfile, если сохранить его в хранилище системы управления версиями (git).
Не использовать latest (последний) тег – он подобен SNAPSHOT для пользователей Maven. Метки подключаются из-за слоистой файловой природы контейнеров. Вы ведь не хотите иметь сюрпризы при построении образа несколько месяцев, а потом выяснить, что приложение не может быть запущено, так как родительский слой (из-за Dockerfile) был заменен новой версией, которая не является обратно совместимой, или из кэша сборки была получена неправильная "последняя" версия. Тега latest также следует избегать при применении контейнеров в производстве, так как невозможно отследить, какая версия образа выполняется.
Не выполнять более одного процесса в одном контейнере - контейнеры идеально подходят для выполнения лишь одного процесса (HTTP, сервер приложений, база данных), но если имеется более одного процесса, могут возникнуть дополнительные проблемы с управлением, извлечением журналов и обновлением их по отдельности.
Не хранить учетные данные в виде образов. Используйте переменные среды, ведь для этого не требуется жестко кодировать имя пользователя/пароль в образе. Используйте переменные среды для получения этой информации вне контейнера. Отличный пример этого принципа - образ Постгреса.
Не запускать процессы от имени пользователя root - "По умолчанию docker контейнеры выполняются от имени пользователя root. По мере «взросления» docker контейнеров могут стать доступны секретные по умолчанию параметры. На данный момент требуемый root опасен для других и может быть доступен не во всех средах. Ваш образ должен использовать инструкцию USER, чтобы указать пользователя, не являющегося root, для контейнеров, которые будут запускаться".
Не полагайтесь на IP-адреса - каждый контейнер имеет свой собственный внутренний IP-адрес, и он может измениться, если вы запустите и остановите контейнер. Если приложению или микросервису требуется связь с другим контейнером, используйте переменные среды для передачи соответствующего имени хоста и порта из одного контейнера в другой.