По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Предыдущая статья этого цикла:
Устранение неполадок коммутации Cisco
Следующая статья этого цикла:
Устранение неисправностей EtherChannel
Case #1
На рисунке представлена топология, состоящая из трех коммутаторов, и между коммутаторами у нас есть два канала связи для резервирования. Коммутатор А был выбран в качестве корневого моста для VLAN 1. Когда вы имеете дело со связующим деревом, лучше всего нарисовать небольшую схему сети и записать роли интерфейса для каждого коммутатора (назначенного, не назначенного/альтернативного или заблокированного). Обратите внимание, что одним из каналов связи между коммутатором A и коммутатором C является интерфейс Ethernet (10 Мбит). Все остальные каналы — это FastEthernet.
Мы используем команду show spanning-tree для проверки ролей интерфейса для коммутатора A и коммутатора C. Вы видите, коммутатор C выбрал свой интерфейс Ethernet 0/13 как корневой порт, а интерфейс FastEthernet 0/14 выбран в качестве альтернативного порта. Это не очень хорошая идея. Это означает, что мы будем отправлять весь трафик вниз по линии 10 Мбит, в то время как 100 Мбит не используется вообще. Когда коммутатор должен выбрать корневой порт он выберет его следующим образом:
Выбирается интерфейс, который имеет самую низкую стоимость для корневого моста.
Если стоимость равная, выбирается наименьший номер интерфейса. Обычно стоимость интерфейса Ethernet выше, чем Fast Ethernet, поэтому он должен выбрать интерфейс FastEthernet.
Почему коммутатор выбрал интерфейс Ethernet 0/13?
Мы видим, что интерфейс Ethernet 0/13 и FastEthernet0/14 имеют одинаковую стоимость. Затем коммутатор С выберет самый низкий номер интерфейса, который является interface Ethernet 0/13.
После проверки конфигурации интерфейса, видно, что кто-то изменил стоимость интерфейса на 19 (по умолчанию для интерфейсов FastEthernet).
SwitchC(config)#interface Ethernet 0/13
SwitchC(config-if)#no spanning-tree cost 19
Уберем настройки команды cost.
После того, как мы убрали настройки команды cost, видно, что состояние порта изменилось. FastEthernet 0/14 теперь является корневым портом, а стоимость интерфейса Ethernet 0/13 равна 100 (это значение по умолчанию для интерфейсов Ethernet). Задача решена!
Извлеченный урок: убедитесь, что интерфейс, которым вы хотите сделать в качестве корневого порта, имеет наименьшую стоимость пути.
Case #2
Итак, новый сценарий. Все интерфейсы равны (FastEthernet). Коммутатор A является корневым мостом для VLAN 10, и после проверки ролей интерфейса мы находим следующее:
Хм, интересно... Коммутатор A является корневым мостом, а FastEthernet 0/17 был выбран в качестве резервного порта. Это то, что вы видите каждый день. Коммутатор B выбрал корневой порт, а все остальные интерфейсы являются альтернативными портами. Мы ничего не видим на коммутаторе С.
Мы видим, что Коммутатор A и Коммутатор B используют связующее дерево для VLAN 10. Коммутатор C, однако, не использует связующее дерево для VLAN 10. В чем может быть проблема?
Конечно, неплохо проверить, работают ли интерфейсы на коммутаторе C или нет (но, конечно, это то, что вы уже изучили и сделали в первой статье).
Интерфейсы выглядят хорошо. VLAN 10 активна на всех интерфейсах коммутатора C. Это означает, что остовное дерево должно быть активным для VLAN 10.
Давайте еще раз посмотрим на это сообщение. Это говорит о том, что остовное дерево для VLAN 10 не существует. Есть две причины, по которым можно увидеть это сообщение:
Для VLAN 10 нет активных интерфейсов.
Spanning-дерево было отключено для VLAN 10.
Мы подтвердили, что VLAN 10 активна на всех интерфейсах коммутатора C, поэтому, может быть, связующее дерево было отключено глобально?
SwitchC(config)#spanning-tree vlan 10
Вот так выглядит лучше! Теперь связующее дерево включено для VLAN 10 и работает ... проблема решена! Эта проблема может показаться немного странной, но она появляется ее время от времени в реальном мире. Сценарий, который мы рассмотрели раньше, - это событие из реальной жизни, где клиент, которому поставщик беспроводной связи отключил остовное дерево для интерфейсов, которые подключаются к точке беспроводного доступа. Ниже то, что клиент ввел на коммутаторе:
SwitchC(config)#interface fa0/1
SwitchC(config-if)#no spanning-tree vlan 10
SwitchC(config)#
В интерфейсе они набрали no spanning-tree vlan 10, но как вы видите, что они оказались в режиме глобальной конфигурации. Нет команды для отключения остовного дерева на интерфейсе, подобного этой, поэтому коммутатор думает, что вы ввели глобальную команду для отключения остовного дерева. Коммутатор принимает команду отключения остовного дерева для VLAN 10 и возвращает вас в режим глобальной конфигурации... проблема решена!
Извлеченный урок: проверьте, включено ли связующее дерево.
Case #3
Давайте продолжим по другому сценарию! Та же топология... наш клиент жалуется на плохую работу. Начнем с проверки ролей интерфейсов:
Посмотрите на картинку выше. Видите ли вы, что интерфейс FastEthernet 0/16 на коммутаторе B и коммутаторе C обозначены? На Коммутаторе A все интерфейсы обозначены. Как вы думаете, что произойдет, когда один из наших коммутаторов переадресует трансляцию или должен передать кадр? Правильно! У нас будет цикл ...
Обычно в этой топологии интерфейсы FastEthernet 0/16 и 0/17 на коммутаторе C должны быть альтернативными портами, поскольку коммутатор C имеет худший ID моста. Так как они оба обозначены, мы предполагаем, что Коммутатор C не получает BPDU на этих интерфейсах.
Так почему же остовное дерево провалилось здесь? Здесь важно помнить, что связующему дереву требуются блоки BPDU, передаваемые между коммутаторами для создания топологии без петель. BPDU могут быть отфильтрованы из-за MAC access-lists, VLAN access-maps или из-за spanning-tree toolkit?
SwitchA#show vlan access-map
SwitchB#show vlan access-map
SwitchC#show vlan access-map
Ни на одном из коммутаторов нет VLAN access maps.
SwitchA#show access-lists
SwitchB#show access-lists
SwitchC#show access-lists
Нет списков доступа...
Нет port security... как насчет команд, связанных с остовным деревом?
Вот что-то есть!Фильтр BPDU был включен на интерфейсах FastEthernet 0/16 и 0/17 коммутатора B. Из-за этого коммутатор C не получает BPDU от коммутатора B.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#no spanning-tree bpdufilter enable
SwitchB(config-if)#interface fa0/17
SwitchB(config-if)#no spanning-tree bpdufilter enable
Удалим настройки фильтра BPDU.
Теперь вы видите, что FastEthernet 0/16 и 0/17 являются альтернативными портами и блокируют трафик. Наша топология теперь без петель... проблема решена!
Извлеченный урок: убедитесь, что блоки BPDU не заблокированы и не отфильтрованы между коммутаторами.
Case #4
Новая топология. Коммутатор A был выбран в качестве корневого моста для VLAN 10. Все интерфейсы являются FastEthernet каналами.
После использования команды show spanning-tree vlan 10 вот, что мы видим. Все интерфейсы одинаковы, но по какой-то причине коммутатор B решил выбрать FastEthernet 0/16 в качестве корневого порта. Разве вы не согласны с тем, что FastEthernet 0/13 должен быть корневым портом? Стоимость доступа к корневому мосту ниже, чем у FastEthernet 0/16.
Используем команду show spanning-tree interface, чтобы проверить информацию о spanning-tree для каждого интерфейса. Как вы можете видеть, существует только связующее дерево для VLAN 1, активное на интерфейсе FastEthernet 0/13 и 0/14.
Есть несколько вещей, которые мы могли бы проверить, чтобы увидеть, что происходит:
Во-первых, всегда полезно проверить, активно ли связующее дерево для определенной VLAN. Можно отключить spanning-tree с помощью команды no spanning-tree vlan X. В этом сценарии связующее дерево активно для VLAN 10, потому что мы можем видеть на FastEthernet 0/16 и 0/17.
Мы знаем, что остовное дерево активно глобально для VLAN 10, но это не значит, что оно активно на всех интерфейсах. Мы можем использовать команду show interfaces switchport, чтобы проверить, работает ли VLAN 10 на интерфейсе FastEthernet 0/13 и 0/14. Это отобразит нам некоторую интересную информацию. Вы видите, что эти интерфейсы оказались в режиме доступа, и они находятся в VLAN 1.
SwitchB(config)#interface fa0/13
SwitchB(config-if)#switchport mode trunk
SwitchB(config-if)#interface fa0/14
SwitchB(config-if)#switchport mode trunk
Давайте изменим режим интерфейсов на магистральный, чтобы трафик VLAN 10 мог проходить через эти интерфейсы.
Ну вот, теперь все намного лучше выглядит. Трафик VLAN 10 теперь передается по интерфейсу FastEthernet 0/13 и 0/14, и вы видите, что интерфейс FastEthernet 0/13 теперь выбран в качестве корневого порта. Задача решена!
Извлеченный урок: убедитесь, что VLAN активна на интерфейсе, прежде чем рассматривать проблемы связующего дерева.
В следующей статье мы расскажем, как траблшутить проблемы с EtherChannel.
Привет, дорогой читатель! Если ты когда-нибудь задавался вопросом – как перенести файл с хостовой машины на виртуальную в Hyper-V, то эта статья для тебя! Дело в том, что не всегда представляется возможным организовать сетевую связность между хостом и виртуальной машиной, а иногда это и вовсе не нужно. К счастью, в Hyper-V предусмотрена простая возможность переноса файлов прямо на виртуальные машины (как Windows так и Linux и другие) с помощью PowerShell и сейчас мы про неё расскажем.
Важно отметить, что данная функционал стал доступен только в 3 версии PowerShell. Поэтому проверьте установленную у себя версию. Для этого в консоли PowerShell введите команду $PSVersionTable
Процесс
Итак, сразу раскроем все карты. Для переноса файлов на гостевые (виртуальные) машины нужно использовать команду со следующим синтаксисом:
Copy-VMFile -Name “Имя виртуальной машины” -SourcePath ?Путь кфайлукоторыйхотим перенести? -DestinationPath ?Путь кпапке на виртуальной машинекуда хотимположить файл? -CreateFullPath -FileSource Host
Основой команды является часть Copy-VMFile, которая, в терминологии PowerShell, называется командлетом (Cmdlet) далее следуют ключи командлета, определяющие параметры и правила выполнения команды. Например, в примере выше, c помощью ключа -Name мы указываем имя виртуальной машины, на которую хотим скопировать файл, путь к которому указываем в ключе -SoucePath. Директория, в которую мы хотим поместить файл на виртуальной машине указывается в ключе -DestinationPath. Ключ -CreateFullPath создаст директорию, если её ещё нет. Ну и -FileSource Host означает, что источником, с которого мы переносим файл является хостовый сервер.
Однако, если вы выполните команду на текущем этапе без предварительной подготовки виртуальной машины, то получите следующую ошибку:
Чтобы этого избежать, необходимо предварительно включить в параметрах виртуальной машины поддержку гостевых сервисов (Guest Services). Для этого зайдите в параметры виртуальной машины, далее выберите Сервисы Интеграции (Integration Services) и поставьте галочку напротив Гостевые сервисы (Guest Services).
Или просто введите команду Enable-VMIntegrationService -Name ?Guest Service Interface? -VMName “Имя виртуальной машины”
После этого следует ввести команду Copy-VMFiles ещё раз, после чего начнётся копирование файлов с хоста в указанную директорию на виртуальной машине. Данный способ подходит для файлов любых размеров, ограничением является только используемое виртуальной машиной дисковое пространство.
На данный момент Kubernetes является одной из самых интересных технологий в мире DevOps. В последнее время вокруг него образовалось очень много хайпа, по одной простой причине, и причина эта – всемогущие контейнеры.
Компания Docker Inc. привлекла народное внимание к контейнерам с помощью маркетинговых компаний о своем прекрасном продукте (у нас есть статья о первоначальной настройке Docker). Но что интересно, Docker – не первопроходец в мире контейнеров, но они положили начало их победоносному походу по миру. Что же было в начале? А в начале были Linux контейнеры, внимание к которым также возросло после такого ажиотажа вокруг Docker контейнеров, при этом и повысив потребность к контейнерным оркестраторам.
Давайте поближе познакомимся с Кормчим – он же Kubernetes. Первоначально это являлось разработкой Google, для управления их гигантской инфраструктурой, состоящей из миллионов контейнеров. В какой-то момент Google отдал Кормчего в люди, а именно - Cloud Native Computing Foundation. На данный момент, Docker добавил Kubernetes в свои сборки как один из вариантов оркестраторов наравне с Docker Swarm.
Теперь Kubernetes также будет частью сборок Docker Community и Docker Enterprise Edition.
Общий обзор Кормчего
Пожалуй, тут нужно разъяснить: Kubernetes является греческим именем кормчего или управляющего кораблём
В зарубежных коммьюнити Кормчий носит несколько названий – Kubernetes, k8s или kube и является платформой с открытым кодом. Данная платформа позволяет автоматизировать операции с контейнерами – запуск, масштабирование, управление контейнизированными приложениями и так далее. Kubernetes может помочь вам сохранить десятки часов жизни и бесценного времени.
Kubernetes позволяет вам помещать в кластер группы хостов с контейнерами и управлять этими кластерами. Эти кластеры могут работать в публичных, частных и гибридных облаках – может, однажды, даже в Хогвартсе откажутся от сложных заклинаний в пользу Kubernetesа.
Как я уже упомянул, Kubernetes изначально является разработкой Google, но будет также нелишним знать, что Kubernetes включен во многие облачные коммерческие предложения Корпорации Добра.
Сам Google запускает более чем 2 миллиарда контейнеров в неделю. Это почти 300 миллионов контейнеров в день с помощью своей внутренней платформы Borg. Эта платформа – предшественник Kubernetes. Все ошибки Borg были учтены и исправлены в Кормчем./
Использование Kubernetes позволяет получать радость от управления и запуска контейнизированных приложений – он автоматизирует запуск и откаты сборок, мониторит запущенные сервисы – т.е вы можете узнать о том, что что-то пойдет не так еще до непосредственной инициации процесса.
Кроме того, Kubernetes управляет ресурсами и может масштабировать необходимые ресурсы для приложений в зависимости от того, сколько им требуется, для того, чтобы избежать лишней траты ресурсов.
Как работает Kubernetes?
Посмотрите на схему с официального сайта (ссылка ниже):
Как вы видите, Kubernetes это очень сложная система (особенно если сравнивать с нативным оркестратором Docker Swarm). Чтобы понять, как он работает, необходимо сначала понять его базовые принципы.
Желаемое состояние
Желаемое состоятие (Desired state) – это один из базовых концептов Kubernetes. Вы можете указать необходимое состояние для запуска контейнеров в т.н Подах. То есть, к примеру, если контейнер почему-то перестал работать, Kubernetes заново создаст Под основываясь на указанном желаемом состоянии.
Kubernetes всегда проверяет состояние контейнеров в кластере, и этим занимается т.н Kubernetes Мастер, который является частью плоскости управления. Можно использовать объект kubectl – он напрямую взаимодействует с кластером для установки или изменения Desired State через Kubernetes API.
Объекты Kubernetes
Обратимся к официальной документации Kubernetes: объект в Kubernetes это «запись о намерениях» (record of intent) – после создания объекта, Kubernetes будет постоянно проверять наличие этого объекта. При создании объекта, вы сообщаете Кормчему как должна выглядеть загрузка вашего кластера, иначе говоря – каково его желаемое состояние.
Состояние сущностей в системе в любой взятый момент времени представлено Kubernetes объектами. Кроме того, объекты также служат как дополнительный уровень абстракции над интерфейсом контейнеров. Вы можете напрямую взаимодействовать с сущностями объектов вместо взаимодействия с контейнерами. Ниже приведем список базовых объектов в Kubernetes.
Под (Pod) – наименьшая запускаемая единица в ноде. Это группа контейнеров, которые должны работать вместе. Довольно часто (но не всегда) в поде находится только один контейнер;
Сервис(Service) – данный объект используется для обозначения логической суммы подов и политик, используемых для доступа к подам;
Раздел (Volume) – директория, которая доступна всем контейнерам внутри пода;
Именные пространства (Namespaces) – виртуальные кластеры, поддерживаемые физическим кластером;
Также в Kubernetes есть несколько контроллеров, которые построены на базовых объектах и они предоставляют дополнительные фичи. Ниже список данных контроллеров:
ReplicaSet - проверяет что какое-то количество копий подов также все время запущено;
Deployment - используется для смены текущего состояния на желаемое состояние;
StatefulSet - используется для контроля над развертыванием и доступов к разделам;
DaemonSet - используется для копирования пода на все ноды кластера или только на указанные ноды;
Job - используется для реализации какой-то задачи и прекращения существования после завершения задачи или после указанного времени
Плоскость управления в Kubernetes
Плоскость управления в Kubernetes используется для установки кластера в желаемое состояние, и для этого Kubernetes выполняет множество задач автоматически – старт и перезагрузка контейнеров, изменение количества реплик приложения и так далее.
Различные части плоскости управления, такие как Kubernetes Мастер и процесс kubelet задают тон тому, как Kubernetes взаимодействует с вашим кластером. Плоскость управления содержит записи о всех объектах Kubernetes в системе и запускает бесконечные петли управления для контроля состояния объектов. В каждый момент времени эти петли будут реагировать на изменения в кластере и будет приводить состояние всех объектов в системе из текущего состояния в желаемое. Представьте себе правительство страны, которое проверяет все ли работают и существуют в соответствии с законом.
Kubernetes Мастер являются частью плоскости управления, и выполняет такую же задачу по сохранению желаемого состояния во всем вашем кластере. Команда kubectl является интерфейсом для взаимодействия с мастером в кластере через API.
В документации написано: «мастер» - это группа процессов, управляющих состоянием кластера. Как правило, все эти процессы запущены одной ноде в кластере и эта нода также называется мастер-нодой. Мастер-нода также может быть реплицирована для избыточности и отказоустойчивости.
Каждый мастер в кластере являет собой совокупность следующих процессов:
kube-apiserver - единственная точка управления для целого кластера. Команда cubectl взаимодействует напрямую через API;
kube-controller-manager - управляет состоянием кластера, управляя различными контроллерами;
kube-scheduler - планирует задачи на всех доступных нодах в кластере;
Ноды в Kubernetes
Ноды в Kubernetes – это ваши «сервера» - виртуалки, физические и так далее, которые находятся в кластере и на которых запущены ваши приложения. Ноды также контролируются мастером и постоянно мониторятся для того, чтобы устанавливать желаемое состояние для приложений. Раньше они назывались «миньонами» - но не теми желтыми милахами из мультика. Каждая нода в кластере держит два процесса:
kubelet– интерфейс между нодой и мастером;
kube-proxy – сетевая прокси, через которую проходят сервисы, указанные в API на каждой ноде. Также эта прокси может совершать простой TCP и UDP проброс портов;
Установка Kubernetes
Теперь давайте посмотрим как это работает. Для этого необходимо установить Kubernetes у вас на сервере. Нужно скачать и установить Docker Community Edition версий 17.12.+ и затем для локального запуска нужно установить Minikube.
Ссылка для скачивания Docker Community Edition - здесь;
Ссылка для скачивания Minikube - тут (MiniKube)
При использовании Minikube надо помнить, что создается локальная виртуальная машина и запускает кластер, состоящий из одной ноды. Но ни в коем случае не используйте его для продакшена – Minikube служит исключительно для тестирования и разработки.
Для запуска однонодного кластера достаточно лишь выполнить команду minikube start. Бадумс, вы одновременно запустили виртуальную машину, кластер и сам Kubernetes.
$minikube start
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
Kubectl is now configured to use the cluster.
Loading cached images from config file.
Для проверки установки надо ввести команду kubectl version
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", GitTreeState:"clean", BuildDate:"2018-01-04T20:00:41Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}