По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В одной из предыдущих статей мы рассматривали такой инструмент сетевого инженера как Puppet. Как мы выяснили, это решение экономит кучу времени администратора в сетях, которые насчитывают большое количество узлов. При этом в силу кроссплатформенности данное решение позволяет осуществлять настройку различных операционных систем и их версий для корректной работы сети. Эта программа имеет клиент-серверную архитектуру, то есть периферийные машины, на которых установлена клиентская часть, запрашивают и получают обновленные файлы с актуальными параметрами конфигурации, а затем программа осуществляет обновление параметров операционной системы в автоматическом режиме. Сегодня мы разберем конкретные примеры использования данного решения -зачем оно нужно и где оно применяется.
На самом деле, сфера применения данного решения довольно широка. Это и небольшая локальная сеть группы разработчиков небольшого приложения на Android, сети покрупнее у компаний вроде небольших торговых сетей, сети больших организаций (таких, например, как сеть промышленного предприятия), и сети мегакорпораций, насчитывающие внутри себя десятки тысяч узлов.
Как мы и писали ранее, манифесты Puppet, которые пишутся на языке, имеющем определенное сходство с Ruby (на котором и написана, в общем-то программа Puppet), хранятся в хранилище на сервере. Актуальные конфигурации настроек выдаются по запросам от клиентских машин. Это позволяет осуществлять быструю передачу однотипных настроек конфигурации, а затем устанавливать их параллельно на каждой клиентской машине, используя ее аппаратные мощности.
Это решение применяется во многих компаниях. Официальными партнерами Puppet являются Нью-йоркская фондовая биржа NYSE, которая является частью межконтинентальной фондовой биржи ICE. На текущий момент более 75% серверов ICE управляются посредством Puppet. Применение данного решения позволило снизить нагрузку на администратора теперь один администратор без снижения производительности может обслуживать в 2,2 раза больше серверов, чем раньше. Значительно повышается скорость подготовки среды там, где раньше требовалось 1-2 дня, Puppet справляется примерно за полчаса. Кроме этого, Puppet замечательно справляется с передачей настроек безопасности, что позволяет обеспечить общую безопасность во всей системе, исключая уязвимости на периферии.
Также использует Puppet такой представитель IT-индустрии, как компания Splunk.Inc. Эта компания занимается разработкой систем анализа данных для крупных корпораций и имеет офисы в 12 странах мира. С помощью Puppet здесь реализованы улучшения работы облачной технологии, а также улучшилась поддержка конечных пользователей. Специалисты компании отмечают значительное ускорение развертывания сети, и более эффективное управление клиентской средой, за счет лучшей согласованности Puppet по сравнению с ранними программными решениями. Кроме того, Puppet экономит время разработчиков если ранее многие машины требовали ручной корректировки настроек, то сейчас все происходит автоматически, позволяя выделять высвобождаемое время для разработки новых программных решений и обслуживания пользователей.
Еще одним ярким примером эффективного применения Puppet является компания Staples один из ведущих производителей канцтоваров в мире. У этой компании широко разветвлённая сеть офисов, поэтому построение надежной и эффективной сети это одна из приоритетных задач. Используя решения Puppet, корпорация Staples развертывает сети более эффективно, а за счет отличной совместимости Puppet с различными операционными системами и другими программными продуктами, Staples успешно комбинирует решения различных команд разработчиков, подбирая и внедряя наиболее эффективные из них в свою систему управления сетью. Также специалисты компании Staples отмечают высокую надежность и эффективность данного решения.
Если же упоминать использование Puppet в сравнительно небольших организациях, то администраторы небольших компаний также отмечают гибкость и удобство этой системы. Если компания насчитывает до 500 сотрудников, то она будет иметь не слишком крупную сеть. Но даже в этом случае сетевой инженер должен произвести настройку каждой машины. Разумеется, настраивать вручную несколько сотен рабочих станций - дело неблагодарное. Поэтому Puppet серьезно сокращает время на обслуживание сети и позволяет админу заняться другими задачами.
На базе нашего опыта реализации проектов, хайринга, консультаций с действующими техническими тренерами по Cisco в сетевых академиях мы сформировали уникальную программу курса, которая на наш взгляд, позволит человека с нуля (без начальных знания) освоить сетевые технологии (всею необходимую теорию, коммутацию, маршрутизацию, настройка и траблшутинг), а также курс прекрасно подойдет для DevOps специалистов, которые хотят углубить свои знания по сетям.
В курсе мы используем примеры конфигураций, лабораторные работы и тестирование в разрезе вендора Cisco - именно с Cisco конфигами и сетапами связан курс. Именно поэтому прохождение курса даст вам нужную базу для сдачи CCNA и частично подготовит к CCNP.
Давайте разберемся в деталях.
Для кого этот курс?
Новички: если вы начинающий специалист и хотите прокачать свои скиллы и знания по сетевым технологиям и DevOps, то мы обучим вас с нуля всем необходимым навыкам, а наши онлайн-тренажеры позволят вам отточить приобретенные знания на практике;
Опытный инженер: данный курс пригодится вам, если вы уже работаете с корпоративными сетями и хотите расширить набор знаний, узнать куда движется тренд технологий, что нового появится в стеке, а также освежить в памяти теоретические знания и потренироваться на тренажерах;
Full-stack специалистам: если вы DevOps инженер, инженер-телефонист, сотрудник оператора связи или хотите просто развить свой профессиональный кругозор, то этот курс позволит вам прокачать знания в корпоративных сетях и разговаривать на одном языке с опытными специалистам.
Полная программа онлайн-курса
Мы тщательно продумали программу курса шаг за шагом, где блок за блоком в указанном ниже порядке вы будете осваивать тот или иной блок, с тестированием и лабораторной работой.
Введение в сетевые технологии
Модель OSI
Маршрутизатор. Коммутатор. Хаб. Что это и в чем разница?
IP, LAN и WAN, TCP и UDP - deep dive в основы
DNS, Ethernet, VLSM, ARP - что это?
Как вашу сеть будут атаковать злоумышленники?
NAT на пальцах и введение в IPv6
Сравнение проводных и беспроводных сетей и режимы передачи данных
Что такое VPN, DHCP, MAC и QoS - важнейшее
Что такое витая пара и как ее обжать?
Иерархическая модель сети от Cisco и почему сегментация сетей так важна?
ОС, CLI, структура команд и траблшутинг в Cisco IOS
Про VLAN (Virtual Local Area Network)
Настройка сетей VLAN
Настройка маршрутизации между сетями VLAN с использованием конфигурации ROS (Router-on-a-Stick)
TCP и UDP
Протоколы TCP/IP 4 уровня: TCP и UDP
Популярные приложения TCP/IP
Установление и прекращение TCP соединения
Что нужно знать: про TCP и UDP
Принципы построения коммутируемых сетей
Принципы коммутации и маршрутизации
Работа с маршрутизатором
Базовая конфигурация маршрутизатора
Настройка статических маршрутов
Настройка NAT на Cisco
Port Forwarding: теория и настройка Cisco
Протокол динамической маршрутизации EIGRP
EIGRP (Enhanced Interior Gateway Routing Protocol) что это?
Базовая настройка протокола EIGRP для IPv4
Полное руководство по EIGRP
Протокол динамической маршрутизации OSPF
OSPF что это?
Настройка базового протокола OSPFv2 для одной области
Поиск и устранение неполадок в работе OSPFv2 для одной области
Настройка OSPFv2 для нескольких областей
Протокол динамической маршрутизации BGP (Border Gateway Protocol)
BGP (Border Gateway Protocol)- что это?
Полное руководство по BGP
Говорим про Route Redistribution
Перераспределение маршрутов (Route redistribution)
Про DHCP (Dynamic Host Configuration Protocol)
Все, что вам нужно знать про DHCP
Рассказываем про динамические адреса
Настройка DHCP на оборудовании Cisco
Пример настройки DHCPv6
Как настроить DHCPv6 форвардинг сообщений между DHCP - клиентом и DHCP - сервером на Cisco
Настройка DHCP Snooping и Dynamic Arp Inspection на Cisco
Пошаговая настройка DHCP Snooping и Dynamic Arp Inspection на Cisco
Технология, которая защитит от подмены DHCP сервера
Траблшутинг DHCP на оборудовании Cisco
Настройка протокола DHCP с помощью команд Cisco IOS
Листы контроля доступа (ACL)
Основы IPv4 Access Control Lists
Соответствие пакетов в IP ACL
Wildcard в ACL: бинарные обратные маски
Стандартные листы контроля доступа (ACL)
Расширенные листы контроля доступа (Extended ACL)
ACL check - анализ списков доступа сетевого оборудования Cisco
Настройка стандартных именованных ACL-списков
Настройка расширенных ACL-списков
Протокол Spanning Tree (STP)
Протокол Spanning Tree (STP) - что это?
Агрегация по технологии EtherChannel
Настройка EtherChannel на Cisco
Настройка LACP и PAgP на Cisco
Как с минимальным даунтаймом на продакшн оборудовании настроить EtherChannel
Устранение неисправностей EtherChannel
На примерах объясним, как происходит устранение неисправностей EtherChannel
Настройка EtherChannel
Поиск и устранение неполадок в работе EtherChannel
WLAN (беспроводные сети)
Топологии беспроводных сетей
Анатомия защищенного соединения в беспроводных сетях KIP, CCMP и GCMP. Про безопасность Wi-Fi
Рассказываем про безопасность Wi-Fi. Подробно про TKIP, CCMP, GCMP, WPA, WPA2 и WPA3
Настройка VPN (Site-To-Site IPSec, DMVPN
Настройка Site-To-Site IPSec VPN на Cisco
Настройка DMVPN на оборудовании Cisco
Dynamic Multipoint VPN - гибкое и масштабируемое решение в области виртуальных частных сетей от компании Cisco
Частный траблшутинг и устранение неисправностей
Траблшутинг NAT/PAT на Cisco
Устранение неисправностей DHCP на Cisco
FHRP траблшутинг на Cisco
Траблшутинг Network Management Protocols
Сброс пароля на коммутаторах и маршрутизаторах Cisco
Troubleshooting в Cisco IOS
Проверка и отладка настроек NAT
Пройти курс
Как происходит обучение
Поговорим как будет происходить ваше обучение в нашей онлайн образовательной системе.
Изучаете тему
В курсе - практические видеоуроки и материал для чтения:
Выполняете задания
В темпе, который подходит именно вам:
Как в игре, но только будет еще и полезно.
Если возникнут вопросы - поможем найти нужный материал
Чат с участниками обучения и наш бот будут всегда на связи.
Пройти курс
Финальный тест и получение сертификата
Добавляете сертификат в свое резюме ;)
Виртуализация часто применяется для поиска более простого способа решения некоторых проблем, отмеченных в начальных статьях этой темы, таких как разделение трафика. Как и все в мире сетевой инженерии, здесь есть компромиссы. На самом деле, если вы не нашли компромисс, вы плохо искали. В этом разделе будут рассмотрены некоторые (хотя, конечно, не все) различные компромиссы сложности в области виртуализации сети. Основой этого обсуждения будет триада компромиссов сложности:
Состояние: количество состояний и скорость, с которой изменяется состояние в сети (особенно в плоскости управления).
Оптимизация: оптимальное использование сетевых ресурсов, включая такие вещи, как трафик, следующий по кратчайшему пути через сеть.
Поверхность: количество слоев, глубина их взаимодействия и широта взаимодействия.
Поверхности взаимодействия и группы связей общих рисков
Каждая система виртуализации, когда-либо задуманная, реализованная и развернутая, создает в некотором роде общий риск. Например, рассмотрим одну линию, по которой передается несколько виртуальных каналов, каждый из которых передает трафик. Должно быть очевидным (на самом деле тривиальным) наблюдение, что в случае отказа одного физического канала произойдет сбой всех виртуальных каналов. Конечно, вы можете просто перенаправить виртуальные каналы на другой физический канал. Правильно? Может быть, а может и нет. Рисунок 1 иллюстрирует это.
С точки зрения A и D, есть две линии, доступные через B и C, каждая из которых обеспечивает независимое соединение между хостом и сервером. В действительности, однако, и провайдер 1, и провайдер 2 приобрели виртуальные каналы через единственное соединение у провайдера 3. Когда единственное соединение в сети провайдера 3 выходит из строя, трафик может быть перенаправлен с основного пути через провайдера 1 на путь через провайдера. 2, но поскольку оба канала используют одну и ту же физическую инфраструктуру, ни одна из них не сможет передавать трафик.
Говорят, что эти два звена в этой ситуации разделяют одну общую судьбу, потому что они являются частью Shared Risk Link Group (SRLG). Можно найти и обойти SRLG или ситуации с shared fate, но это усложняет плоскость управления и/или управление сетью. Например, невозможно обнаружить эти shared fate без ручного тестирования различных ситуаций отказа на физическом уровне или изучения сетевых карт, чтобы найти места, где несколько виртуальных каналов проходят по одному и тому же физическому каналу. В ситуации, описанной на рисунке 1, найти ситуацию с shared fate было бы почти невозможно, поскольку ни один из провайдеров, скорее всего, не скажет вам, что использует линию от второго провайдера, показанного на рисунке как провайдер 3, для предоставления услуг.
Как только эти ситуации с shared fate обнаружены, необходимо предпринять некоторые действия, чтобы избежать серьезного сбоя в работе сети. Обычно для этого требуется либо вводить информацию в процесс проектирования, либо усложнять дизайн, либо вводить информацию в плоскость управления (см. RFC8001 в качестве примера типа сигнализации, необходимой для управления группами SRLG в плоскости управления, спроектированной трафиком). По сути, проблема сводится к следующему набору утверждений:
Виртуализация - это форма абстракции.
Абстракция удаляет информацию о состоянии сети с целью снижения сложности или предоставления услуг за счет реализации политики.
Любое нетривиальное сокращение информации о состоянии сети так или иначе снизит оптимальное использование ресурсов.
Единственным противодействием конечному состоянию из этих трех, является протекание информации через абстракцию, поэтому можно восстановить оптимальное использование ресурсов - в этом случае отказ одного канала не вызывает полного отказа потока трафика через сеть. Единственное решение, таким образом, - сделать абстракцию сквозной абстракцией, что снизит эффективность абстракции при контроле области действия состояния и реализации политики.
Поверхности взаимодействия и наложенные плоскости управления
В сетевой инженерии принято накладывать друг на друга два протокола маршрутизации или две плоскости управления. Хотя это не часто рассматривается как форма виртуализации, на самом деле это просто разделение состояния между двумя различными плоскостями управления для контроля количества состояний и скорости изменения состояний, чтобы уменьшить сложность обеих плоскостей управления. Это также часто встречается при запуске виртуальных наложений в сети, поскольку между головным и хвостовым узлами туннеля будет существовать нижележащая плоскость управления, обеспечивающая достижимость, и плоскость управления наложением, обеспечивающая достижимость в виртуальной топологии. Две наложенные друг на друга плоскости управления будут взаимодействовать иногда неожиданным образом. Для иллюстрации используется рисунок 2.
На рисунке 2:
Каждый маршрутизатор в сети, включая B, C, D и E, использует две плоскости управления (или, если это проще, протоколы маршрутизации, отсюда протокол 1 и протокол 2 на рисунке).
Протокол 1 (оверлей) зависит от протокола 2 (базовый) для обеспечения доступности между маршрутизаторами, на которых работает протокол 1.
Протокол 2 не содержит информации о подключенных устройствах, таких как A и F; вся эта информация передается в протоколе 1.
Протокол 1 требует гораздо больше времени для схождения, чем протокол 2.
Более простой путь от B к E проходит через C, а не через D.
Учитывая этот набор протоколов, предположим, что C на рисунке 2 удален из сети, двум управляющим плоскостям разрешено сходиться, а затем C снова подключается к сети. Каков будет результат? Произойдет следующее:
После удаления C сеть снова объединится с двумя путями в локальной таблице маршрутизации в B:
F доступен через E.
E доступен через D.
После повторного подключения C к сети протокол 2 быстро сойдется.
После повторной конвергенции протокола 2 лучший путь к E с точки зрения B будет через C.
Следовательно, у B теперь будет два маршрута в локальной таблице маршрутизации:
F доступен через E.
E достижимо через C.
B перейдет на новую информацию о маршрутизации и, следовательно, будет отправлять трафик к F через C до того, как протокол 1 сойдется, и, следовательно, до того, как C узнает о наилучшем пути к F.
С момента, когда B начинает пересылку трафика, предназначенного для F в C, и момента, когда протокол 1 сойдется, трафик, предназначенный для F, будет отброшен.
Это довольно простой пример неожиданного взаимодействия наложенных протоколов. Чтобы решить эту проблему, вам необходимо ввести информацию о состоянии конвергенции протокола 1 в протокол 2, или вы должны каким-то образом заставить два протокола сходиться одновременно. В любом случае вы по существу добавляете состояние обратно в два протокола, чтобы учесть их разницу во времени конвергенции, а также создавая поверхность взаимодействия между протоколами.
Примечание: Этот пример описывает фактическое взаимодействие конвергенции между IS-IS и BGP, или протоколом Open Shortest Path First (OSPF) и BGP. Чтобы решить эту проблему, более быстрый протокол настроен на ожидание, пока BGP не сойдется, прежде чем устанавливать какие-либо маршруты в локальной таблице маршрутизации.