По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Чтобы перенести сетевой трафик групп распределенных портов в группу агрегации каналов (Link Aggregation Group - LAG), нужно создать новую группу LAG на распределяющем коммутаторе.
Порядок действий
В веб-клиенте vSphere перейдите к распределяющему коммутатору.
Во вкладке Configure (Конфигурация) разверните Settings (Настройки) и выберите LACP()
Щелкните на значок New Link Aggregation Group(Создать группу объединенных ссылок)
Введите имя для новой LAG.
Установите количество портов для LAG. Установите такое же количество портов для группы LAG, как и количество портов в канале портов LACP на физическом коммутаторе. Порт LAG имеет ту же функцию, что и восходящая линия (uplink) на распределяющем коммутаторе. Все порты LAG образуют команду NIC в контексте LAG.
Выберите режим согласования LACP для группы LAG.
Активный режимВсе порты LAG находятся в активном режиме согласования. Порты LAG инициируют согласование с каналом порта LACP на физическом коммутаторе, отправляя пакеты LACP.Пассивный режимПорты LAG находятся в режиме пассивного согласования. Они отвечают на пакеты LACP, которые они получают, но не согласовывают с LACP.
Если порты с поддержкой LACP на физическом коммутаторе находятся в активном режиме, вы можете установить порты LAG в пассивный режим и наоборот.
Выберите режим балансировки нагрузки из алгоритмов хэширования, которые определяет LACP.
Алгоритм хеширования должен совпадать с алгоритмом, установленным для канала порта LACP на физическом коммутаторе.
Установите виртуальную локальную сеть (VLAN) и политики NetFlow для LAG. Этот параметр активен, когда переопределение политик VLAN и NetFlow для отдельных портов восходящей линии связи включено в группе портов восходящей линии связи. Если вы установите политики VLAN и NetFlow для LAG, они переопределят политики, установленные на уровне группы портов восходящей линии связи.
Нажмите OK
Итоги
Новая LAG не используется в порядке группировки и отработки отказа распределенных групп портов. Физические сетевые карты не назначены портам LAG.
Как и в случае автономных каналов связи, LAG представляется на каждом хосте, связанном с распределяющим коммутатором. Например, если вы создаете LAG1 с двумя портами на распределяющем коммутаторе, LAG 1 с двумя портами создается на каждом хосте, связанном с распределяющим коммутатором.
Что делать дальше
Установить LAG как резервную в конфигурации группирования и отработки отказа распределенных групп портов. Таким образом, вы создаете промежуточную конфигурацию, которая позволяет переносить сетевой трафик в группу LAG без потери сетевого подключения.
Есть разные причины, по которым все идет не так в наших сетях: люди делают ошибки в своих настройках, оборудование может выйти из строя, обновления программного обеспечения могут включать ошибки, а изменение структуры трафика может вызвать перегрузку в наших сетях. Для устранения этих ошибок существуют различные подходы, и некоторые из них более эффективны, чем другие.
Устранение неполадок состоит из 3 этапов:
Все это начинается, когда кто-то или что-то сообщает о проблеме. Часто это будет пользователь, который звонит в службу поддержки, потому что что-то работает не так, как ожидалось, но также возможно, что вы обнаружите проблемы из-за мониторинга сети (Вы ведь контролируете свою сеть?). Следующий шаг - это диагностика проблемы, и очень важно найти ее корень. Как только вы обнаружите проблему, вы реализуете (временное) решение.
Диагностика проблемы является одним из самых важных шагов, чтобы устранить неполадки в сети. Для начала нам нужно найти первопричину проблемы. И для этого, необходимо выполнить ряд действий:
Сбор информации: в большинстве случаев отчет о проблеме не дает нам достаточно информации. Пользователи просто нам сообщают, что "сеть не работает" или "Мой компьютер не работает", но это нам ничего не дает. Мы должны собирать информацию, задавая нашим пользователям подробные вопросы, или мы используем сетевые инструменты для сбора информации.
Анализ информации: как только мы собрали всю информацию, мы проанализируем ее, чтобы увидеть, что не так. Мы можем сравнить нашу информацию с ранее собранной информацией или другими устройствами с аналогичными конфигурациями.
Устранение возможных причин: нам нужно подумать о возможных причинах и устранить потенциальные причины проблемы. Это требует досконального знания сети и всех протоколов, которые в ней задействованы.
Гипотеза: после определения возможных причин, вы в конечном итоге получите список этих причин, которые могут вызывать проблему работу сети. Мы выберем самую наиболее вероятную причину возникновения проблемы.
Проверка гипотезы: мы проверим нашу гипотезу, чтобы увидеть, правы мы или нет. Если мы правы, у нас есть победа...если мы ошибаемся, мы проверяем наши другие возможные причины.
Если вы применяете структурированный подход для устранения неполадок, вы можете просто "следовать интуиции" и запутаться, потому что вы забыли, что вы уже пробовали или нет. Это упрощает поиск проблемы, если вы работаете вместе с другими сетевыми администраторами, потому что вы можете поделиться шагами, которые вы уже выполнили.
Вот шаги поиска проблемы в хорошей блок-схеме. Мы называем это структурированным подходом к устранению неполадок.
Вместо того чтобы выполнять все различные этапы структурированного подхода к устранению неполадок, мы также можем перейти от этапа "сбор информации" непосредственно к шагу "гипотеза" и пропустить этапы "анализ информации" и "устранение возможных причин". По мере того, как вы наберётесь опыта в устранении неполадок, вы сможете пропустить некоторые шаги.
Шаги, которые мы пропускаем, выделены синим цветом. Если вас ваши интуиция подведет, то вы потеряете много времени. Если вы правы, то вы сэкономите много времени.
Устранение возможных причин является важным шагом в процессе устранения неполадок, и есть несколько подходов, как вы можете это сделать.
Вот они:
Сверху вниз;
Снизу вверх;
Разделяй и властвуй;
Отследить путь трафика;
Поиск отличий;
Замена компонентов.
Давайте пройдемся по разным подходам один за другим!
Метод "сверху вниз"
"Сверху вниз" означает, что мы начинаем с верхней части модели OSI (прикладной уровень) и продвигаемся дальше вниз. Идея заключается в том, что мы проверим приложение, чтобы увидеть, работает ли оно, и предположим, что если определенный уровень работает, то все нижеперечисленные уровни также работают. Если вы посылаете эхо-запрос с одного компьютера на другой (ICMP), то можете считать, что уровни 1,2 и 3 работают. Недостатком этого подхода является то, что вам нужен доступ к приложению, в котором устраняете неполадки.
Метод "снизу вверх"
"Снизу вверх" означает, что мы начинаем с нижней части модели OSI и будем продвигаться вверх. Мы начнем с физического уровня, который означает, что мы проверяем наши кабели и разъемы, переходим к канальному уровню, чтобы увидеть, работает ли Ethernet, связующее дерево работает нормально, безопасность портов не вызывает проблем, VLAN настроены правильно, а затем переходим на сетевой уровень. Здесь мы будем проверять наши IP-адреса, списки доступа, протоколы маршрутизации и так далее. Этот подход является очень тщательным, но и отнимает много времени. Если вы новичок в устранении неполадок рекомендуется использовать этот метод, потому что вы устраните все возможные причины проблем.
"Разделяй и властвуй"
Разделяй и властвуй означает, что мы начинаем с середины OSI-модели. Вы можете использовать эту модель, если не уверены, что нисходящее или восходящее движение более эффективно. Идея заключается в том, что вы попытаетесь отправить эхо-запрос с одного устройства на другое. Если ping работает, вы знаете, что уровень 1-3 работает, и вы можете продвинуться вверх по модели OSI.
Если эхо-запрос терпит неудачу, то вы знаете, что что-то не так, и вы будете причину проблемы в нижней части модели OSI.
"Путь трафика"
Изучение путь следования трафика очень полезно. Сначала мы попытаемся отправить эхо-запрос с хоста A на хост B. В случае сбоя мы проверим все устройства на его пути. Сначала мы проверим, правильно ли настроен коммутатор A, и, далее, мы перейдем на коммутатор B, проверим его, а затем перейдем к маршрутизатору A.
"Поиск отличий"
Этот подход вы, скорее всего, делали и раньше. Поиск отличий в конфигурации или вывод команд show может быть полезным, но очень легко что-то пропустить. Если у вас есть несколько маршрутизаторов филиала с похожей конфигурацией, и только один не работает, вы можете заметить отличие в конфигурациях. Сетевые администраторы, которые не имеют большого опыта, обычно используют этот подход. Возможно, вам удастся решить проблему, но есть риск, что вы на самом деле не знаете, что делаете.
"Замена компонентов"
Последний подход к решению нашей проблемы - это замена компонентов. Допустим, у нас есть сценарий, в котором компьютер не может получить доступ к сети. В приведенном выше примере мы можем заменить компьютер, чтобы устранить любую вероятность того, что компьютер является проблемой. Мы можем заменить кабель, и, если мы подозреваем, что коммутатор не работает или неверно настроен, мы можем заменить его на новый и скопировать старую конфигурацию, чтобы увидеть, есть ли какие-либо проблемы с оборудованием.
На данный момент 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"}