По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В предыдущей части нашей серии OSPF мы рассмотрели варианты ручной фильтрации маршрутов. Теперь мы обсудим маршруты по умолчанию и сравним OSPFv2 с OSPFv3.
Предыдущие статьи:
Расширенные возможности OSPF: Области
OSPF: создание конкретных типов областей
Ручная фильтрация маршрутов OSPF
Маршрут по умолчанию (Default Routes)
Мы изучили с вами, что OSPF может автоматически генерировать маршрут по умолчанию, когда это необходимо. Это происходит с некоторыми специальными типами областей. Например, если вы настраиваете totally stubby area, требуется маршрут по умолчанию, и OSPF генерирует этот маршрут автоматически из ABR.
Чтобы повысить гибкость ваших проектов, маршруты по умолчанию, вводимые в нормальную область, могут быть созданы любым роутером OSPF. Для создания маршрута по умолчанию используется команда default-information originate.
Эта команда содержит два варианта:
Вы можете объявлять 0.0.0.0 в домен OSPF, при условии, что объявляемый роутер уже имеет маршрут по умолчанию.
Вы можете объявлять 0.0.0.0 независимо от того, имеет ли объявляемый роутер уже маршрут по умолчанию. Этот второй метод выполняется путем добавления ключевого слова always к default-information originate
Рисунок 1 - топология OSPF
Используя нашу простую топологию из рисунка 1 еще раз, давайте настроим ATL2 для введения маршрута по умолчанию в нормальную, не магистральную область 1.
ATL2#conf t
Enter configuration commands, one per line. End with CNTL/Z .
ATL2 (config)#router ospf 1
ATL2 (config-router)#default-information originate always
ATL2 (config-router)#end
ATL2#
Обратите внимание, что в этом примере мы используем ключевое слово always, чтобы убедиться, что ATL2 генерирует маршрут по умолчанию независимо от того, есть ли у устройства уже маршрут по умолчанию в его таблице маршрутизации.
Вот проверка на ORL:
show ip route
Сравнение OSPFv2 и OSPFv3
Каким бы удивительным ни был OSPFv2, он не может маршрутизировать префиксы IPv6 для нас. Это работу выполняет OSPFv3. Хорошей новостью для вас является тот факт, что вы можете использовать почти все, что вы узнали о OSPFv2 при переходе на протокол OSPFv3. Полная перестройка протокола не проводилась, и было сохранено как можно больше функциональных возможностей и этапов настройки.
Как вы узнаете далее, OSPFv3 предлагает использование семейств адресов в конфигурации, что делает этот протокол подходящим для переноса префиксов IPv6 или даже префиксов IPv4 с соответствующим семейством адресов.
В конце этой статьи демонстрируется «стандартная» конфигурация OSPFv3, а также конфигурация семейства адресов.
Важно иметь представление о ключевых сходствах и различиях между v2 и v3 протоколов OSPF. Вот сходства, которые описаны ниже:
В OSPFv3 процесс маршрутизации не создается явно. Включение OSPFv3 на интерфейсе приведет к созданию процесса маршрутизации и связанной с ним конфигурации.
Идентификатор маршрутизатора по-прежнему является 32-разрядным значением в OSPFv3, и процесс выбора идентификатора маршрутизатора остается таким же.
OSPF автоматически предпочитает loopback интерфейс любому другому виду, и он выбирает самый высокий IP-адрес среди всех loopback интерфейсов.
Если никаких loopback интерфейсов нет, то выбирается самый высокий IP-адрес в устройстве.
Вот некоторые ключевые отличия:
Эта функция отличается от OSPF версии 2, в которой интерфейсы косвенно включены с помощью режима конфигурации устройства.
При использовании nonbroadcast multiaccess интерфейса в OSPFv3 необходимо вручную настроить устройство со списком соседей.
Соседние устройства идентифицируются по их идентификатору устройства.
В IPv6 можно настроить множество префиксов адресов на интерфейсе.
В OSPFv3 все префиксы адресов на интерфейсе включены по умолчанию.
Вы не можете выбрать определенные префиксы адресов для импорта в OSPFv3; либо импортируются все префиксы адресов в интерфейсе, либо никакие префиксы адресов в интерфейсе не импортируются.
В отличие от OSPF версии 2, несколько экземпляров OSPFv3 могут быть запущены на линии.
Традиционная (стандартная) настройка OSPFv3
Чтобы продемонстрировать (и попрактиковать) конфигурацию OSPFv3 часть настроек мы отбросили.
Вот конфигурация нашей магистральной области (область 0) и не магистральной области (область 1) с использованием «традиционного» подхода OSPFv3.
ATL# configuration terminal
Enter configuration commands, one per line . End with CNTL/Z .
ATL(config)#ipv6 unicast-routing
ATL(config)#interface fa0/0
ATL(config-if)#ipv6 address 2001:1212:1212::1/64
ATL(config-if)#ipv6 ospf 1 area 0
ATL(config-if)#interface loopback0
ATL(config-if)#ipv6 address 2001:1111:1111::1/64
ATL(config-if)#ipv6 ospf 1 area 0
ATL(config-if)#end
ATL#
Обратите внимание, насколько знакомым кажется этот подход к настройке, он аналогичен настройке OSPFv2. Обратите внимание также, что мы должны глобально включить возможность одноадресной маршрутизации IPv6 на устройстве. Это не является действием по умолчанию. Вы также должны понять, что это не требуется для запуска IPv6 на интерфейсах, это просто требование сделать маршрутизацию трафика IPv6 на роутере.
Вот конфигурация наших двух других устройств:
ATL2#conf t
Enter configuration commands, one per line. End with CNTL/Z .
ATL2 (config)#ipv6 unicast-routing
ATL2 (config)#int fa0/0
ATL2 (config-if)#ipv6 address 2001:1212:1212::2/64
ATL2 (config-if)#ipv6 ospf 1 area 0
ATL2 (config-if)#
*Mar 28 09:23 :25 .563 : %0SPFv3-5-ADJCHG: Process 1, Nbr
192.168.20.1 on FastEthernet0/0 from LOADING to FULL, Loading Done
ATL2 (config-if)#int fa1/0
ATL2 (config-if)#ipv6 address 2001:2323:2323::2/64
ATL2 (config-if)#ipv6 ospf 1 area 1
ATL2 (config-if)#end
ATL2#
ORL#conf t
Enter configuration commands, one per line . End with CNTL/Z .
ORL(config)#ipv6 unicast-routing
ORL(config)#int fa1/0
ORL(config-if)#ipvб address 2001:2323:2323::3/64
ORL(config-if)#ipvб ospf 1 area 1
ORL(config-if)#end
ORL#
Теперь настало время для проверки. Обратите внимание, что я выполню все это на устройстве ORL для краткости. Обратите внимание еще раз на все замечательные сходства с OSPFv2:
show ipv6 route
show ipv6 ospf neighbor
show ipv6 ospf database
Конфигурация Семейства Адресов OSPFv3
Давайте завершим эту статью изучением стиля конфигурации семейства адресов OSPFv3. Помните, что это позволит нам использовать этот единый протокол для передачи префиксов IPv4 и IPv6.
Вот пример подхода к конфигурации семейства адресов OSPFv3:
BOS (config)#ipv6 unicast-routing
BOS (config)#router ospfv3 1
BOS (config-router)#address-family ipv6 unicast
BOS (config-router-af)#area 1 range 2001:DB8:0:0::0/128
BOS (config-router-af)#end
BOS#conf t
BOS (config)#interface fa1/0
BOS (config-if)#ipv6 ospf 1 area 1
Важно то, что если вы уже знакомы с семействами адресов из другого протокола (например, BGP), то эта настройка покажется вам очень простой. Также учтите, что подход к настройке OSPFv3 на подинтерфейсах не меняется.
Docker - программное обеспечение с открытым исходным кодом, предназначенное для упрощения и ускорения разработки приложений. Это набор продуктов PaaS (Platform as a Service) - Платформа как услуга, которые создают изолированные виртуализированные среды для создания, развертывания и тестирования приложений.
Несмотря на то, что программное обеспечение относительно просто в управлении, существуют некоторые специфичные для Docker термины, в которых путаются новые пользователи. Докерфайлы, образы, контейнеры, тома и другая терминология должны быть освоены раз и навсегда.
Понимание элементов Docker ускорит обучение работе с ним. Первый вопрос, который задают многие пользователи: "В чем разница между образом Docker и контейнером?"
Что такое Docker Image
Образ Docker (Docker Image) - это неизменяемый файл, содержащий исходный код, библиотеки, зависимости, инструменты и другие файлы, необходимые для запуска приложения.
Из-за того, что образы предназначены только для чтения их иногда называют снимками (snapshot). Они представляют приложение и его виртуальную среду в определенный момент времени. Такая согласованность является одной из отличительных особенностей Docker. Он позволяет разработчикам тестировать и экспериментировать программное обеспечение в стабильных, однородных условиях.
Так как образы являются просто шаблонами, их нельзя создавать или запускать. Этот шаблон можно использовать в качестве основы для построения контейнера. Контейнер - это, в конечном счете, просто образ. При создании контейнера поверх образа добавляет слой, доступный для записи, что позволяет менять его по своему усмотрению.
Образ - это шаблон, на основе которого создается контейнер, существует отдельно и не может быть изменен. При запуске контейнерной среды внутри контейнера создается копия файловой системы (docker образа) для чтения и записи.
Можно создать неограниченное количество образов Docker из одного шаблона. Каждый раз при изменении начального состояния образа и сохранении существующего состояния создается новый шаблон с дополнительным слоем поверх него.
Таким образом, образы Docker могут состоять из ряда слоев, каждый из которых отличается от предыдущего. Слои образа представляют файлы, доступные только для чтения, поверх которых при создании контейнера добавляется новый слой.
Что такое Docker Container?
Контейнер Docker (Docker Container) - это виртуализированная среда выполнения, в которой пользователи могут изолировать приложения от хостовой системы. Эти контейнеры представляют собой компактные портативные хосты, в которых можно быстро и легко запустить приложение.
Важной особенностью контейнера является стандартизация вычислительной среды, работающей внутри контейнера. Это не только гарантирует, что ваше приложение работает в идентичных условиях, но и упрощает обмен данными с другими партнерами по команде.
Контейнеры работают автономно, изолированно от основной системы и других контейнеров, и потому ошибка в одном из них не влияет на другие работающие контейнеры, а также поддерживающий их сервер. Docker утверждает, что эти блоки «обеспечивают самые сильные возможности изоляции в отрасли». Поэтому при разработке приложения вам не придется беспокоиться о безопасности компьютера.
В отличие от виртуальных машин, где виртуализация выполняется на аппаратном уровне, контейнеры виртуализируются на уровне приложений. Они могут использовать одну машину, совместно использовать ее ядро и виртуализировать операционную систему для выполнения изолированных процессов. Это делает контейнеры чрезвычайно легкими, позволяя сохранять ценные ресурсы.
Образа Docker в сравнении с Docker контейнерами
Говоря о разнице между образами и контейнерами, было бы неверно противопоставлять их друг-другу. Оба элемента тесно связаны между собой и являются основными шестерёнками Docker.
Из определения терминов образ и контейнер выше, легко установить связь между ними: образы могут существовать без контейнеров, тогда как для существования контейнеров необходимо запустить образ. Поэтому контейнеры зависят от изображений и используют их для создания среды выполнения и запуска приложения.
Эти две концепции существуют как важные компоненты (или, скорее, фазы) в процессе запуска контейнера Docker. Наличие рабочего контейнера является конечной «фазой» этого процесса, указывая, что он зависит от предыдущих этапов и компонентов. Именно поэтому образ docker по существу управляют контейнерами и формируют их.
Из Dockerfile к образу и контейнеру
Все начинается с последовательности инструкций, определяющих способ построения определенного образа Docker – Dockerfile. Данный файл автоматически выполняет команды скрипта и создает образ Docker.
Для создания образа из Dockerfile используется команда docker build.
Затем образ используется в качестве шаблона, который разработчик может скопировать и использовать для запуска приложения. Приложению необходима изолированная среда для выполнения - контейнер.
Эта среда - не просто виртуальное «пространство». Она полностью зависит от образа, на базе которого была создана. Исходный код, файлы, зависимости и двоичные библиотеки, которые находятся в образе Docker, составляют контейнер.
Чтобы создать слой контейнера из образа, используйте команду docker create.
Наконец, после запуска контейнера из существующего образа вы запускаете его службу и запускаете приложение.
Создание образа из контейнера.
Если вы вносите изменения в исходный образ и хотите сохранить его для дальнейшей работы, можно сохранить измененный образ, сделав снимок текущего состояния контейнера. Таким образом, слой контейнера прикрепляется поверх образа, в конечном итоге создавая новый неизменяемый образ. В результате получается два образа Docker, полученные из одной файловой системы.
Заключение
Данная статья должна помочь понять, что такое образ Docker, что такое контейнер и как они связаны. Если поймете процесс создания контейнера, поймете разницу между образом и контейнером.
На сегодняшний день двумя наиболее популярными веб-серверами с открытым исходным кодом для работы в Интернете являются HTTP-сервер Apache и Nginx. Более 50% веб-сайтов в мире работают на этих двух веб-серверах. В течение почти двух десятилетий веб-сервер Apache обслуживал около 60 процентов веб-сайтов в мире, пока не появился его конкурент Nginx (произносится как «engine-x»). В связи с резким ростом объемов трафика данных и количества пользователей всемирной паутины, Nginx был введен для преодоления ограничений производительности веб-серверов Apache. Nginx, разработанный для обеспечения более высокого уровня параллелизма, может быть развернут в качестве автономного веб-сервера и в качестве внешнего прокси-сервера для Apache и других веб-серверов. Прочитать про установку и настойку этих серверов можно в этой статье
Кстати! Еще у нас есть статья по сравнению Apache против IIS. Welcome 🤓
Краткий обзор Apache
Apache был разработан для доставки веб-контента, доступ к которому осуществляется через Интернет. Он известен тем, что играл ключевую роль в начальном росте интернета. Apache - это программное обеспечение с открытым исходным кодом, разработанное и поддерживаемое открытым сообществом разработчиков и работающее в самых разных операционных системах. Архитектура включает в себя ядро Apache и модули. Основной компонент предоставляет базовую серверную функцию, поэтому он принимает соединения и управляет параллелизмом. Различные модули соответствуют различным функциям, которые выполняются по каждому запросу. Конкретное развертывание Apache может быть сконфигурировано для включения различных модулей, таких как функции безопасности, управление динамическим контентом или для базовой обработки HTTP-запросов.
Модель «один сервер делает все» стала ключом к раннему успеху Apache. Однако по мере увеличения уровня трафика и увеличения количества веб-страниц и ограничения производительности настройка Apache на работу с реальным трафиком усложнялась.
Краткий обзор Nginx
Nginx был разработан специально для устранения ограничений производительности веб-серверов Apache. Производительность и масштабируемость Nginx обусловлены архитектурой, управляемой событиями. Он значительно отличается от подхода Apache. В Nginx каждый рабочий процесс может одновременно обрабатывать тысячи HTTP-соединений. Следовательно, Nginx - это легковесная, масштабируемая и высокопроизводительная реализация. Эта архитектура делает обработку больших и флуктуирующих нагрузок на данные гораздо более предсказуемой с точки зрения использования ОЗУ, использования ЦП и задержки.
Nginx также имеет богатый набор функций и может выполнять различные роли сервера:
Обратный прокси-сервер для протоколов HTTP, HTTPS, SMTP, POP3 и IMAP
Балансировщик нагрузки и HTTP-кеш
Интерфейсный прокси для Apache и других веб-серверов, сочетающий гибкость Apache с хорошей производительностью статического контента Nginx
Apache против Nginx: сравнение их богатых наборов функций
Простота
Разрабатывать и обновлять приложения на Apache очень просто. Модель «одно соединение на процесс» позволяет очень легко вставлять модули в любой точке логики веб-обслуживания. Разработчики могут добавлять код таким образом, что в случае сбоев будет затронут только рабочий процесс, выполняющий код. Обработка всех других соединений будет продолжаться без помех.
Nginx, с другой стороны, имеет сложную архитектуру, поэтому разработка модулей не легка. Разработчики модулей Nginx должны быть очень осторожны, чтобы создавать эффективный и точный код, без сбоев, и соответствующим образом взаимодействовать со сложным ядром, управляемым событиями, чтобы избежать блокирования операций.
Производительность
Производительность измеряется тем, как сервер доставляет большие объемы контента в браузер клиента, и это важный фактор. Контент может быть статическим или динамическим. Давайте посмотрим статистику по этому вопросу.
Статический контент
Nginx работает в 2,5 раза быстрее, чем Apache, согласно тесту производительности, выполняемому до 1000 одновременных подключений. Другой тест с 512 одновременными подключениями показал, что Nginx примерно в два раза быстрее и потребляет меньше памяти. Несомненно, Nginx имеет преимущество перед Apache со статическим контентом. Поэтому, если вам нужно обслуживать одновременный статический контент, Nginx является предпочтительным выбором.
Динамический контент
Результаты тестов Speedemy показали, что для динамического контента производительность серверов Apache и Nginx была одинаковой. Вероятная причина этого заключается в том, что почти все время обработки запросов расходуется в среде выполнения PHP, а не в основной части веб-сервера. Среда выполнения PHP довольно похожа для обоих веб-серверов.
Apache также может обрабатывать динамический контент, встраивая процессор языка, подобного PHP, в каждый из его рабочих экземпляров. Это позволяет ему выполнять динамический контент на самом веб-сервере, не полагаясь на внешние компоненты. Эти динамические процессоры могут быть включены с помощью динамически загружаемых модулей.
Nginx не имеет возможности обрабатывать динамический контент изначально. Чтобы обрабатывать PHP и другие запросы на динамический контент, Nginx должен перейти на внешний процессор для выполнения и дождаться отправки визуализированного контента. Однако этот метод также имеет некоторые преимущества. Поскольку динамический интерпретатор не встроен в рабочий процесс, его издержки будут присутствовать только для динамического содержимого.
Поддержка ОС
Apache работает во всех операционных системах, таких как UNIX, Linux или BSD, и полностью поддерживает Microsoft Windows. Nginx также работает на нескольких современных Unix-подобных системах и поддерживает Windows, но его производительность в Windows не так стабильна, как на платформах UNIX.
Безопасность
И Apache, и Nginx являются безопасными веб-серверами. Apache Security Team существует, чтобы предоставить помощь и советы проектам Apache по вопросам безопасности и координировать обработку уязвимостей безопасности. Важно правильно настроить серверы и знать, что делает каждый параметр в настройках.
Гибкость
Веб-серверы могут быть настроены путем добавления модулей. Apache долго загружал динамические модули, поэтому все модули Apache поддерживают это.
Nginx Plus (Nginx Plus - это программный балансировщик нагрузки, веб-сервер и кэш контента, построенный на основе открытого исходного кода Nginx) также использует модульную архитектуру. Новые функции и возможности могут быть добавлены с программными модулями, которые могут быть подключены к работающему экземпляру Nginx Plus по требованию. Динамические модули добавляют в Nginx Plus такие функции, как геолокация пользователей по IP-адресу, изменение размеров изображений и встраивание сценариев Lua в модель обработки событий Nginx Plus. Модули создаются как Nginx, Inc., так и сторонними разработчиками.
Большинство необходимых функциональных возможностей основного модуля (например, прокси, кэширование, распределение нагрузки) поддерживаются обоими веб-серверами.
Поддержка и документация
Важным моментом, который следует учитывать, является доступная справка и поддержка веб-серверов среди прочего программного обеспечения. Поскольку Apache был популярен так долго, поддержка сервера довольно распространена повсеместно. Для главного сервера и для основанных на задачах сценариев, связанных с подключением Apache к другому программному обеспечению, имеется большая библиотека документации первого и стороннего производителя.
Наряду с документацией многие инструменты и веб-проекты содержат инструменты для начальной загрузки в среде Apache. Это может быть включено в сами проекты или в пакеты, поддерживаемые отделом упаковки вашего дистрибутива.
Apache, как правило, получает большую поддержку от сторонних проектов просто из-за своей доли рынка и продолжительности времени, в течение которого он был доступен.
В прошлом для Nginx было трудно найти исчерпывающую англоязычную документацию из-за того, что большая часть ранней разработки и документации была на русском языке. Однако на сегодняшний день документация заполнена, и на сайте Nginx имеется множество ресурсов для администрирования и доступной документации от третьих лиц.
Ngnix против Apache: Сравнение лицом к лицу
Подводя итог, вот табличное представление наборов функций:
ОсобенностьApacheNginxПростотаЛегко разрабатывать и внедрять инновации благодаря своей модели «одно соединение на процесс»Сложный в разработке, поскольку он имеет сложную архитектуру для одновременной обработки нескольких соединений.Производительность - Статический контентМедленно в отображении статического контентаВ 2,5 раза быстрее чем Apache и потребляет меньше памятиПроизводительность - Динамический контентОтличная производительность для динамического контентаОтличная производительность для динамического контентаПоддержка операционной системыПоддерживает все ОС - Unix, как и WindowsПоддерживает все ОС - как Unix, так и Windows, однако производительность в Windows сравнительно менее стабильна.БезопасностьЭто безопасный веб-сервер. Понимание и настройка функций безопасности важныЭто безопасный веб-сервер. Понимание и настройка функций безопасности важныГибкостьМожно настроить, добавив модули. Apache имел динамическую загрузку модулей дольше всего.Nginx версии 1.11.5 и Nginx Plus Release R11 представили совместимость для динамических модулей.Поддержка и документацияОтличная поддержка и документация доступны, как это было на рынке в течение очень долгого времени.Несмотря на слабое начало поддержки и документации для Nginx, он быстро рос, поэтому теперь у него есть отличная поддержка ресурсов и доступная документация.
Nginx и Apache - Совместная работа
Для многих приложений Nginx и Apache хорошо дополняют друг друга. Очень распространенным начальным шаблоном является развертывание программного обеспечения Nginx с открытым исходным кодом в качестве прокси-сервера (или Nginx Plus в качестве платформы доставки приложений) перед веб-приложением на основе Apache. Nginx выполняет тяжелую работу, связанную с HTTP - обслуживает статические файлы, кэширует содержимое и разряжает медленные HTTP-соединения - так что сервер Apache может выполнять код приложения в безопасной и защищенной среде.
Итак, что выберите? Apache или Nginx?
Как видно, Apache и Nginx являются мощными, гибкими и способными. Последние версии обоих серверов являются конкурентоспособными во всех областях. Решение о том, какой сервер лучше для вас, во многом зависит от оценки ваших конкретных требований и выбора наилучшего варианта.