По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В предыдущих статьях были рассмотрены три обширные задачи, которые должна решать каждая плоскость управления для сети с коммутацией пакетов, и рассмотрен ряд решений для каждой из этих задач. Первой рассматриваемой задачей было определение топологии сети и ее доступности. Во-вторых, вычисление свободных от петель (и, в некоторых случаях, непересекающихся) путей через сеть. Последняя задача- это реакция на изменения топологии, на самом деле представляет собой набор задач, включая обнаружение и сообщение об изменениях в сети через плоскость управления.
В этой серии лекций мы объединим эти заждачи и решения путем изучения нескольких реализаций распределенных плоскостей управления, используемых для одноадресной пересылки в сетях с коммутацией пакетов. Реализации здесь выбраны не потому, что они широко используются, а потому, что они представляют собой ряд вариантов реализации среди решений, описанных в предыдущих лекциях. В каждом конкретном случае рассматривается базовая работа каждого протокола; в последующих статьях мы будем углубляться в вопросы сокрытия информации и другие более сложные темы в плоскостях управления, поэтому здесь они не рассматриваются.
Классификация плоскости управления
Плоскости управления обычно классифицируются по двум характеристикам. Во-первых, они разделяются в зависимости от того, где вычисляются loop-free пути, будь то на передающем устройстве или выключенном. Плоскости управления, в которых фактические коммутационные устройства непосредственно участвуют в расчете loop-free путей, затем разделяются на основе вида информации, которую они несут о сети. Классификация, основанная на алгоритме, используемом для вычисления loop-free путей, отсутствует, хотя это часто тесно связано с типом информации, передаваемой плоскостью управления.
В то время как централизованные плоскости управления часто связаны с несколькими (или одним, концептуально) контроллерами, собирающими информацию о достижимости и топологии от каждого коммутационного устройства, вычисляющими набор loop-free путей и загружающими полученную таблицу пересылки на коммутационные устройства, концепция гораздо менее строгая. Ц В более общем смысле централизованная плоскость управления означает просто вычисление некоторой части информации о пересылке где-нибудь, кроме фактического устройства пересылки. Это может означать отдельное устройство или набор устройств; это может означать набор процессов, запущенных на виртуальной машине; это может означать вычисление всей необходимой информации о пересылке или (возможно) большей ее части.
Плоскости распределенного управления обычно различаются тремя общими характеристиками:
Протокол, работающий на каждом устройстве и реализующий различные механизмы, необходимые для передачи информации о доступности и топологии между устройствами.
Набор алгоритмов, реализованных на каждом устройстве, используемый для вычисления набора loop-free путей к известным пунктам назначения.
Способность обнаруживать и реагировать на изменения доступности и топологии локально на каждом устройстве.
В распределенных плоскостях управления не только каждый прыжок (hop by hop) с коммутацией пакетов, но и каждый прыжок определяет набор loop-free путей для достижения любого конкретного пункта назначения локально. Плоскости распределенного управления обычно делятся на три широких класса протоколов: состояние канала, вектор расстояния и вектор пути.
В протоколах состояния канала каждое устройство объявляет состояние каждого подключенного канала, включая доступные пункты назначения и соседей, подключенных к каналу. Эта информация формирует базу данных топологии, содержащую каждое звено, каждый узел и каждый достижимый пункт назначения в сети, через который алгоритм, такой как Dijkstra или Suurballe, может быть использован для вычисления набора loop-free или непересекающихся путей. Протоколы состояния канала обычно заполняют свои базы данных, поэтому каждое устройство пересылки имеет копию, которая синхронизируется с каждым другим устройством пересылки.
В протоколах вектора расстояния каждое устройство объявляет набор расстояний до известных достижимых пунктов назначения. Эта информация о достижимости объявляется конкретным соседом, который предоставляет векторную информацию или, скорее, направление, через которое может быть достигнут пункт назначения. Протоколы вектора расстояния обычно реализуют либо алгоритм Bellman-Ford, либо алгоритм Garcia-Luna’s DUAL, либо аналогичный алгоритм для расчета маршрутов без петель в сети.
В протоколах вектора пути, путь к пункту назначения, записывается по мере того, как объявление о маршрутизации проходит через сеть, от узла к узлу. Другая информация, такая как показатели, может быть добавлена для выражения некоторой формы политики, но первичный, свободный от петель, характер каждого пути вычисляется на основе фактических путей, по которым объявления проходят через сеть.
На рисунке 1 показаны эти три типа распределенных плоскостей управления.
На рисунке 1:
В примере состояния связи- вверху каждое устройство объявляет, что оно может достичь любе друге устройство в сети. Следовательно, A объявляет достижимость B, C и D; в то же время D объявляет достижимость 2001:db8:3e8:100::/64 и C, B и A.
В примере вектора расстояния - в середине D объявляет достижимость до 2001:db8:3e8:100:: 24 до C с его локальной стоимостью, которая равна 1. C добавляет стоимость [D,C] и объявляет достижимость до 2001:db8:3e8:100::64 со стоимостью 2 до B.
В примере вектора пути - внизу D объявляет о достижимости до 2001:db8:3e8:100::/24 через себя. C получает это объявление и добавляет себя к [D,C].
Плоскости управления не всегда аккуратно вписываются в ту или иную категорию, особенно когда вы переходите к различным формам сокрытия информации. Некоторые протоколы состояния канала, например, используют принципы вектора расстояния с агрегированной информацией, а протоколы вектора пути часто используют некоторую форму расположения метрик вектора расстояния для увеличения пути при вычислении loop-free путей. Эти классификации - централизованный, вектор расстояния, состояние канала и вектор пути - важны для понимания и знакомства с миром сетевой инженерии.
В данной статье посмотрим и разберем, как создать простейшие ресурсы в облаке AWS (Amazon Web Services) с помощью замечательного инструмента IaaS, под названием Terraform. Для того, чтобы можно было повторить то, о чем пойдет речь в статье необходим действующий аккаунт AWS и рабочая машина (виртуальный сервер) с установленным Terraform, и текстовым редактором Atom + плагин для Terraform.
Первоначальная настройка данных инструментов разбиралась в предыдущих статьях. Описание в статье пойдет под операционную систему CentOS. Вы можете для тренировки использовать на свой вкус любую.
Для начала создадим папку под наш новый проект, можно непосредственно в домашней директории.
sudo mkdir terraform
Создадим первый файл нашего терраформ кода. Можно создать непосредственно в редакторе, через меню или в командной строке sudo touch myterr.tf. Принципиальной разницы, как будет создан файл нет. Если создали через командную строку открываем, как обычный файл в редакторе.
Далее схема работы следующая: пишем код в файле, сохраняем, производим управляющие команды в командной строке для выполнения или проверки данного кода, уничтожения, модификации элементов или объектов в облаке.
Как в начале статьи было сказано, нам необходим аккаунт AWS, чтобы терраформ взаимодействовал с облачной инфраструктурой, а более конкретно нам нужно создать пользователя и получить access key и secret key, для доступа к облаку. Это необходимо для аунтификации Terraform в AWS облаке.
Заходим в AWS консоль и выбираем сервис IAM. Заходим во вкладку пользователи и создаем новую учетную запись. Вводим имя пользователя в пустое поле. Нужно поставить Programmatic Фccess. Далее нажимаем Создать пользователя и попадаем на закладку назначения прав. Тут необходимо присоеденить уже созданный по умолчанию в AWS набор прав администратора. Далее переходим к страничке назначения Tag, тут по желанию вашему, если хотите то можете добавить тэги. Нажимаем кнопку создать пользователя.
Финальное окно будет выглядеть следующим образом.
Получаем те данные, которые нам необходимы для Terraform.
Очень важно - Secret key показывается только один раз!
Теперь в принципе все готово для создания первого ресурса в AWS.
Начинаем с объявления с каким облаком мы работаем.
provider “aws” {
}
Тем самым мы обозначили с каким облачным провайдером мы будем работать. В данном коде в отличии от YAML, количество пробелов не важно. Далее прописываем access key и secret key. В каком регионе будут использоваться ресурсы. Регион мы укажем eu-central-1 – это ЦОД расположенный в Европе во Франфуркте. Старайтесь регион указывать, поближе к себе, чтобы до ресурсов была минимальная задержка прохождения пакетов.
provider “aws” {
access_key = “тут ключ доступа”
secret key = “тут секретный ключ”
region = “eu-central-1”
}
При нажатии Ctrl+S, мы сохраняем и видим, что плагин аккуратно выправляет для удобства написанный код.
Теперь можно сделать первый ресурс. Например, инстанс в Амазон. Добавляем ниже:
resource “aws_instance” “my_название” {
ami = “”
instance_type = “”
}
Для поднятия ресурса необходимо указать 2 минимальные вещи. Это ami – image id и instance_type. Теперь необходимо пойти в указанный регион, открыть EC2 и посмотреть ami интересующего инстанса.
А тип возьмем t2.micro. Данный тип для новых аккаунтов на год бесплатный. Получаем код полностью готовый для развертывания первого инстанса.
В принципе все готово для запуска первого инстанса. Код Terraform будет выглядеть следующим образом:
provider “aws” {
access_key = “тут ключ доступа”
secret key = “тут секретный ключ”
region = “eu-central-1”
}
resource “aws_instance” “TestUbuntu” {
ami = “ami-0767046d1677be5a0”
instance_type = “t2.micro”
}
Запускаем консоль и переходим в директорию, где находится у нас Terraform.
Далее есть небольшой нюанс запуска, чтобы в коде не светить свои access_key и secret_key, эти данные можно убрать, экспортировав в переменные. Делается это следующим образом. С помощью команды export.
export AWS_ACCESS_KEY_ID=ключ
export AWS_SECRET_ACCESS_KEY=ключ
И можно убирать эти 2 строчки из кода.
Теперь запускаем Terraform. Первая команда, которую необходимо сделать это команда terraform init, данная команда пройдется по всем tf файлам, она увидит провайдера и скачает дополнительные файлы, необходимые для запуска в том числе и бинарники. Сам Terraform – это такая оболочка, которая подкачивает все, что ей необходимо.
Следующая команда, которая понадобится это terraform plan, данная команда позволяет посмотреть, что Terraform будет делать. Т.е нечто вроде Whatif. Данная команда очень важна т.к в крупных проектах, позволяет заранее посмотреть, что будет если мы запустим файл терраформа. Вывод ее большой, кусочек представлен на картинке.
Можно увидеть, что добавится. Достаточно удобно. Как мы видим, при команде на deploy, Terraform добавит в амазон 1 instance, т.е 1 виртуальную машину из указанного шаблона, указанного типа и размера.
Непосредственно для deploy, необходимо ввести команду terraform apply, прочитать что Terraform будет делать и явным образом, командой yes подтвердить.
После подтверждения видим следующую картину. Со стороны консоли.
Со стороны амазона спустя полминуты.
Как мы видим сервер создался и проходит инициализацию.
Управление кэш-памятью определяет поведение кэширования для веб-сайта, давая браузерам понять, как часто следует обновлять локально хранящиеся ресурсы.
Что такое cache-control?
Cache-control – это HTTP-заголовок, который определяет поведение браузера при кэшировании. Проще говоря, когда кто-то посещает веб-сайт, то его браузер сохраняет определенные ресурсы, такие как изображения и данные веб-сайта, в хранилище, которое называется кэш. Когда пользователь вновь посещает этот веб-сайт, то cache-control диктует правила, которые определяют, будут ли эти ресурсы загружены из локального кэша данного пользователя, или браузер должен отправить запрос на сервер для получения новых ресурсов. Для более глубокого понимания, что такое cache-control необходимо базовое понимание того, что такое кэширование в браузере и что такое HTTP-заголовки.
Что такое кэширование в браузере?
Как уже было описано выше, кэширование в браузере – это когда веб-браузер сохраняет ресурсы веб-сайта, чтобы не запрашивать их вновь с сервера. Например, фоновое изображение веб-сайта может быть сохранено локально в кэше, чтобы при повторном посещении пользователем данного веб-сайта изображение загружалось из локальных файлов пользователя, и тем самым страница загружалась бы быстрее.
Браузеры хранят эти ресурсы в течение определенного периода времени, известного как время жизни информации (TTL - Time To Live). Если пользователь запросит кэшированный ресурс после истечения TTL, то браузеру придется снова обратиться к серверу, чтобы загрузить новую копию ресурса. Как браузеры и веб-серверы узнают TTL для каждого ресурса? Вот здесь в игру вступают HTTP-заголовки.
Что такое HTTP-заголовки?
Протокол передачи гипертекста (HTTP - Hypertext Transfer Protocol) представляет собой синтаксис для обмена данными во Всемирной паутине, и этот обмен данными состоит из запросов от клиентов к серверам и ответов от серверов к клиентам. Каждый из HTTP-запросов и ответов содержит ряд пар «ключ-значение», которые называют заголовками.
Заголовки содержат большое количество важной информации о каждом сообщении. Например, заголовок запроса обычно содержит:
Информацию о том, какой ресурс запрашивается
Информацию о том, какой браузер использует клиент
Информацию о том, какие форматы данных примет клиент
Заголовки ответов обычно содержат информацию о:
Успешности выполнения запроса
Языке и формате любых ресурсов в теле ответа
Заголовок cache-control может использоваться как в HTTP-запросах, так и в HTTP-ответах.
Что находится внутри заголовка cache-control?
Заголовки состоят из пар «ключ-значение», разделенных двоеточием. Для cache-control «ключ», или часть слева от двоеточия, - это всегда «cache-control». «Значение» - это то, что находится справа от двоеточия. Значений для cache-control может быть несколько, или оно может быть одно. Если их несколько, то они разделяются запятыми.
Эти значения называются директивами, и они определяют, кто может кэшировать ресурс, а также как долго эти ресурсы могут быть кэшированными, прежде чем их необходимо будет обновить. Давайте рассмотрим несколько наиболее распространенных директив cache-control:
cache-control: private
Ответ с директивой private может быть кэширован только клиентом, но никак не посредником, таким как CDN или прокси-сервером. Часто сюда относятся ресурсы, которые содержат личные данные, например, веб-сайт, отображающий личную информацию пользователя.
cache-control: public
Здесь наоборот, директива public говорит о том, что ресурс может хранится в любом кэше.
cache-control: no-store
Ответ с директивой no-store нельзя кэшировать нигде и никогда. Это означает, что при каждом запросе пользователем этих данных, требуется отправить запрос на исходный сервер для их получения. Эта директива, как правило, используется для ресурсов, содержащих конфиденциальные данные, например, информацию о банковском счете.
cache-control: no-cache
Эта директива означает, что кэшированные версии запрошенного ресурса нельзя использовать без предварительной проверки наличия обновленной версии. Обычно это делается с помощью ETag.
ETag – это еще один HTTP-заголовок, который содержит маркер, уникальный для версии ресурса на момент его запроса. Этот маркер меняется на исходном сервере при каждом обновлении ресурса.
Когда пользователь возвращается на страницу с ресурсом под директивой no-cache, клиенту всегда придется подключаться к исходному серверу и сравнивать ETag на кэшированном ресурсе с ETag на сервере. Если они совпадают, то кэшированный ресурс предоставляется пользователю. В противном случае, это означает, что ресурс был обновлен, и клиенту необходимо загрузить обновленную версию, чтобы иметь возможность предоставить его пользователю. Этот процесс гарантирует, что пользователь всегда будет получать самую последнюю версию ресурса без ненужных постоянных загрузок.
cache-control: max-age
Эта директива определяет время жизни информации, или, иными словами, сколько секунд ресурс может находиться в кэше после его загрузки. Например, если max-age установлен на 1800, то это значит, что в течение 1800 секунд (30 минут) после того, как ресурс был впервые запрошен с сервера, пользователю будет предоставляться кэшированная версия этого ресурса при последующих запросах. Если пользователь запросит этот ресурс снова по истечении этих 30 минут, то клиенту необходимо будет запросить новую копию с исходного сервера.
Директива s-maxage предназначена специально для общих кэшей, таких как CDN. Она определяет, как долго эти общие кэши могут продолжать обслуживать ресурс из кэша. Эта директива отменяет действие директивы max-age для некоторых клиентов.
Почему cache-control так важен?
Кэширование в браузере – это отличный способ сохранить ресурсы и, тем самым, улучшить процесс взаимодействия с пользователем в Интернете, но без cache-control этот процесс не был бы столь надежным. Все ресурсы на всех сайтах будут использовать одни и те же правила кэширования, а это значит, что конфиденциальная информация будет кэшироваться также, как и общедоступная информация, а ресурсы, которые часто обновляются, будут кэшироваться на то же время, что и ресурсы, которые редко обновляются.
Cache-control добавляет гибкости, которая делает кэширование в браузере действительно полезным, позволяя разработчикам определять, как будет кэшироваться каждый ресурс. Этот заголовок также позволяет разработчикам устанавливать определенные правила для посредников, что является причиной, по которой сайты, которые используют CDN, как правило, работают лучше, чем сайты, которые этого не делают.