По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Данная статья будет посвящена еще одному проприетарному протоколу компании Cisco Systems - VTP (VLANTrunkingProtocol), который призван решать возможные проблемы в среде коммутации в случае расширения парка оборудования организации. Для начала вспомним что же такое VLAN. VLAN – это Virtual Local Area Network, что дословно переводится как “виртуальная локальная сеть”. При создании VLAN’а хосты физической сети, объединенные общей функцией, выделяются в логическую виртуальную сеть, при этом их физическое местонахождение не имеет значения. Обычно VLAN настраивается на сетевом коммутаторе, по средствам добавления портов, за которыми находятся хосты подлежащие объединению, в группу. Выглядит это примерно так: На слайде приведен случай, когда на коммутаторе настроено два VLAN’a. Порты с 1 по 3 принадлежат VLAN’у 10, а порты с 6 по 8 находятся во VLAN’е 20. Команды, которые вводил администратор для такой конфигурации, примерно такие: Создание VLAN 10 Switch(config)# vlan 10 Switch(config)# interface range fa0/1 - 3 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 10 Создание VLAN 20 Switch(config)# vlan 20 Switch(config)# interface range fa0/5 - 8 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 20 Как видите набор команд довольно простой, но администратор вводил их на единственном коммутаторе. Хосты реальных VLAN’ов могут быть рассредоточены по сети и находиться за разными устройствами, как показано на рисунке: Как видно из рисунка хосты принадлежащие VLAN 10 рассредоточены по сети, они находятся как за коммутатором 1 так и за коммутатором 3. Для того, чтобы они могли корректно взаимодействовать, администратору вручную придется создавать VLAN на каждом устройстве и добавлять в них порты. Реальные сети могут содержать ещё больше VLAN сетей и каждую необходимо прописать вручную, в следствие чего растет вероятность допущения ошибок в конфигурации, которая может привести перекрестному соединению и многочисленным несогласованностям. Для того чтобы исключить вероятность таких ошибок и был разработан протокол VTP, который позволяет устройствам автоматически делиться информацией о настроенных на них VLAN’ах и самостоятельно вносить изменения в конфигурацию. Режимы работы VTP VTP коммутатор имеет два режима работы: Server В этом режиме можно создавать новые и вносить изменения в существующие VLAN’ы. Коммутатор будет обновлять свою базу VLAN’ов и сохранять информацию о настройках во Flashпамяти в файле vlan.dat. Генерирует и передает сообщения как от других коммутаторов, работающих в режиме сервера, так и от клиентов Client Коммутатор в этом режиме будет передавать информацию о VLAN’ах полученную от других коммутаторов и синхронизировать свою базу VLANпри получении VTPобновлений. Настройки нельзя будет поменять через командную строку такого устройства. 3) Transparent В данном режиме коммутатор будет передавать VTPинформацию другим участникам, не синхронизируя свою базу и не генерируя собственные обновления. Настройки VLAN можно поменять лишь для локального коммутатора. Типы сообщений VTP В VTPсуществует три типа сообщений: Advertisement requests Представляет из себя запрос от клиента к серверу на оповещение SummaryAdvertisement Summary advertisements Данное сообщение по умолчанию сервер отправляет каждые 5 минут или сразу же после изменения конфигурации. Subset advertisements Отправляется сразу же после изменения конфигурации VLAN, а также после запроса на оповещение. Стоит отметить, что VTPкоммутатор, который получает информацию о новых VLAN’ах, внесет ее в свою конфигурацию только в том случае, если сообщение пришло от коммутатора с большим номером ревизии. Номер ревизии это некий идентификатор “свежести” базы VLAN. Коммутатор воспринимает базу с наивысшим номером ревизии как самую “свежую” и вносит изменения в свою конфигурацию. Протокол VTPявляется проприетарным, т.е закрытым. Он сильно облегчает жизнь администраторам, работающим с оборудованием Cisco. Для оборудования других производителей существует аналогичный открытый стандарт - GVRP (GARP VLAN Registration Protocol).
img
В Amocrm существует два вида воронок: Воронка продаж и Digital воронка. Обе они являются эффективными инструментами для отдела продаж. Основным элементом построения воронки являются этапы, по которым проходит лид перед тем, как совершить целевое действие. /p> В Amo можно создавать до 10 воронок, в каждой из которой можно настроить до 100 шагов. Как создать воронку продаж в AmoCRM? Технически начало построения воронки начинается с открытия вкладки «Сделки» . По умолчанию к редактированию предлагается воронка со стандартными шагами. Далее можно создавать шаги, которые являются последовательностью этапов продаж. Некоторые из них могут заканчиваться неуспешным статусом, например, отказом клиента от покупки. Самостоятельная настройка воронки продаж Создатели AmoCRM рекомендует следовать следующим правилам при самостоятельной настройке воронки продаж: Создавать шаги, которые являются этапами продаж Разделять этапы по длительности Разделять воронки по отделам Называть этапом конкретное действие Шаги, которые являются этапами продаж Специалисты рекомендуют избегать этапов, которые не содержат шаги, приближающие лид к совершению покупки. Так же не создавайте этапы-напоминания. Конечно, существуют сценарии, в которых клиент не выходит на связь, после отправки заявки, или ему не подошли условия. В таком случае следует создать отдельную воронку, в которой будут существовать неуспешные этапы продаж. Это поможет составить более точную и дифференцированную статистику по продажам. Разделять этапы по длительности Самым лучшим вариантом является обозначение времени для каждого шага. Когда в одном этапе сделки сочетается конкретный срок и задание с неопределенной длительностью, высок риск того, что менеджер может забыть или даже «забить» на выполнение задачи. Если каждый этап имеет свой определенный дедлайн, система пришлет менеджеру напоминание, когда срок вот-вот подойдет к концу. Установить срок выполнения задачи можно в настройках Сделки. Выберите «Создать новую сделку» или «Редактировать» уже существующую. Разделение воронки при работе нескольких отделов Случается, что над одной заявкой может работать более одного отдела. Например, сначала клиент контактирует с колл-центром, потом с персональным менеджером по продажам, и в конце концов с финансовым и юридическим отделом, где заключается договор. В этой ситуации продуктивным способом разделить ответственных по шагам и отследить статистику по каждому отделу. Работа со сделками Сделки перемещаются по этапам воронки, с ними взаимодействуют менеджеры по продажам и другие ответственные, которые к ней прикреплены. Чтобы извлечь максимум пользы от каждого взаимодействия с клиентом, рекомендуется отредактировать поля карточки сделки в зависимости от специфики бизнеса. Это действие, как и редактор воронок, доступно только администратору системы. Подключите веб-форму В AmoCRM есть возможность подключения формы обратной связи с сайта прямо к системе. Это означает, что заявки с сайта будут автоматически поступать в воронку. Периодические покупки Это совершенно новый инструмент в AmoCRM, который позволяет работать с существующими клиентами, строить ожидания и гипотезы, когда они вновь обратятся в компанию. Для активации данного инструмента необходимо перейти в «Настройки» - «Общие настройки» , выбрать Периодические покупки и активировать их. После этого система перенесет администратора в раздел «Покупатели» , где необходимо будет задать условия взаимодействия с постоянными клиентами, задачи и рекламные материалы. Amo будет периодически высылать промо материалы этим покупателям, стимулируя их на покупку.
img
Подаренный компанией Google сообществу Opensource, Kubernetes теперь стал инструментом контейнерного хранения по выбору. Он может управлять и координировать не только среду выполнения докеров, но и среду контейнерного хранения объектов и Rkt. Типичный кластер Kubernetes обычно имеет главный узел и несколько рабочих узлов или Minions. Управление рабочими узлами осуществляется из главного узла, что обеспечивает управление кластером из центральной точки. Важно также отметить, что можно развернуть кластер с одним узлом Kubernetes, который обычно рекомендуется использовать для легких непроизводственных рабочих нагрузок. Для этого можно взять Minikube - инструмент, который управляет кластером K ubernetes с одним узлом в виртуальной машине. В этом руководстве мы рассмотрим многоузловую установку кластера Kubernetes в системе Linux CentOS 7. Это учебное пособие основано на командной строке и требует доступа к окну терминала. Требования Иметь несколько серверов под управлением Centos 7 (1 главный узел, 2 рабочих узла). Рекомендуется, чтобы главный узел содержал по крайней мере 2 ЦП, хотя это не является строгим требованием. Подключение к Интернету на всех узлах. Мы будем извлекать пакеты Kubernetes и докеров из хранилища. Кроме того, необходимо убедиться, что диспетчер пакетов yum установлен по умолчанию и может получать пакеты удаленно. Вам также потребуется доступ к учетной записи с правами sudo или root. В этом учебном пособии я буду использовать свою учетную запись root. Наш 3-узловой кластер будет выглядеть примерно так: Установка кластера Kubernetes на главном узле Для работы Kubernetes потребуется механизм контейнеризации. Для этой установки мы будем использовать docker, так как он самый популярный. На главном узле выполняются следующие шаги. Шаг 1: Подготовить имя узла, брандмауэр и SELinux На главном узле задайте имя хоста и, если у вас нет DNS-сервера, обновите файл /etc/hosts. # hostnamectl set-hostname master-node # cat <<EOF>> /etc/hosts 10.128.0.27 master-node 10.128.0.29 node-1 worker-node-1 10.128.0.30 node-2 worker-node-2 EOF Можно выполнить проверку связи с рабочим узлом 1 и рабочим узлом 2, чтобы убедиться в правильности работы обновленного файла хоста с помощью команды ping. # ping 10.128.0.29 # ping 10.128.0.30 Затем отключите SElinux и обновите правила брандмауэра. # setenforce 0 # sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux # reboot Установите следующие правила брандмауэра для портов. Убедитесь, что каждая команда firewall-cmd возвращает результат. # firewall-cmd --permanent --add-port=6443/tcp # firewall-cmd --permanent --add-port=2379-2380/tcp # firewall-cmd --permanent --add-port=10250/tcp # firewall-cmd --permanent --add-port=10251/tcp # firewall-cmd --permanent --add-port=10252/tcp # firewall-cmd --permanent --add-port=10255/tcp # firewall-cmd –reload # modprobe br_netfilter # echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables Шаг 2: Настройка Kubernetes Repo Нужно будет вручную добавить хранилище Kubernetes, так как оно не установлено по умолчанию в CentOS 7. cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF Шаг 3: Установить Kubeadm и Docker После того, как пакет repo уже готов, вы можете продолжить и установить kubeadm и docker пакеты. # yum install kubeadm docker -y После успешного завершения установки включите и запустите обе службы. # systemctl enable kubelet # systemctl start kubelet # systemctl enable docker # systemctl start docker Шаг 4: Установка Kubernetes Master и настройка пользователя по умолчанию Теперь мы готовы инициализировать Kubernetes Master, но до этого нужно отключить swap, чтобы запустить команду kubeadm init. # swapoff –a Инициализация Kubernetes master - это полностью автоматизированный процесс, управляемый командой kubeadm init, которую необходимо выполнить. # kubeadm init Инициализация Kubernetes master Возможно, потребуется скопировать последнюю строку и сохранить ее в другом месте, поскольку нужно будет запустить ее на рабочих узлах. kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41 Совет: Иногда эта команда может жаловаться на переданные аргументы (args), поэтому отредактируйте ее, чтобы избежать ошибок. Таким образом, вы удалите символ , сопровождающий --token, и ваша последняя команда будет выглядеть следующим образом. kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41 После успешной инициализации Kubernetes необходимо разрешить пользователю начать использование кластера. В нашем случае мы хотим запустить эту установку от имени пользователя root, поэтому мы продолжим выполнение этих команд с этого же имени. Вы можете перейти на пользователя с поддержкой sudo, который вы предпочитаете, и запустить ниже с помощью sudo. Чтобы использовать root, выполните следующие действия: # mkdir -p $HOME/.kube # cp -i /etc/kubernetes/admin.conf $HOME/.kube/config # chown $(id -u):$(id -g) $HOME/.kube/config Чтобы быть пользователем с поддержкой sudo, выполните следующие действия: $ mkdir -p $HOME/.kube $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config $ sudo chown $(id -u):$(id -g) $HOME/.kube/config Теперь проверьте, активирована ли команда kubectl. # kubectl get nodes На этом этапе также можно заметить, что главный узел имеет статус NotReady. Это связано с тем, что сеть модулей еще не развернута в кластере. Pod Network - это сеть наложения для кластера, которая развернута поверх текущей сети узла. Она предназначена для обеспечения возможности подключения через модуль. Шаг 5: Настройка сети модуля Применение сетевого кластера является очень гибким процессом в зависимости от потребностей пользователя и наличия множества доступных вариантов. Так как мы хотим сохранить нашу установку как можно проще, мы будем использовать плагин Weavenet, который не требует никакой конфигурации или дополнительного кода, и он предоставляет один IP-адрес на модуль, что отлично для нас. Для просмотра дополнительных параметров проверьте здесь. Эти команды будут важны для настройки сети модуля. # export kubever=$(kubectl version | base64 | tr -d ' ') # kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever" Теперь, если вы проверите статус главного узла, он должен показать "Ready" # kubectl get nodes Далее мы добавим рабочие узлы в кластер. Настройка рабочих узлов для присоединения к кластеру Kubernetes Следующие шаги будут выполнены на рабочих узлах. Эти шаги должны выполняться на каждом рабочем узле при присоединении к кластеру Kubernetes. Шаг 1: Подготовить имя узла, брандмауэр и SELinux На рабочем узле-1 и рабочем узле-2 задайте имя, а если у вас нет DNS-сервера, то обновите основные и рабочие узлы в файле /etc/hosts. # hostnamectl set-hostname 'node-1' # cat <<EOF>> /etc/hosts 10.128.0.27 master-node 10.128.0.29 node-1 worker-node-1 10.128.0.30 node-2 worker-node-2 EOF Можно выполнить ping master-node для проверки правильности обновленного файла хоста. Затем отключите SElinux и обновите правила брандмауэра. # setenforce 0 # sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux Установите следующие правила брандмауэра для портов. Убедитесь, что все команды firewall-cmd возвращаются успешно. # firewall-cmd --permanent --add-port=6783/tcp # firewall-cmd --permanent --add-port=10250/tcp # firewall-cmd --permanent --add-port=10255/tcp # firewall-cmd --permanent --add-port=30000-32767/tcp # firewall-cmd --reload # echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables Шаг 2: Настройка Kubernetes Repo Вам потребуется добавить хранилище Kubernetes вручную, так как оно не будет предварительно установлено на CentOS 7. cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF Шаг 3: Установить Kubeadm и Docker После того, как пакет repo уже готов, вы можете продолжить и установить kubeadm и docker пакеты. # yum install kubeadm docker -y Запустите и включите обе службы. # systemctl enable docker # systemctl start docker # systemctl enable kubelet # systemctl start kubelet Шаг 4: Присоединение рабочего узла к кластеру Кубернетов Теперь для присоединения к кластеру требуется маркер, созданный kubeadm init. Его можно скопировать и вставить в узлы 1 и 2, если он был скопирован в другом месте. # kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41 Как показано в последней строке, вернитесь к главному узлу и проверьте, присоединились ли рабочие узлы 1 и 2 к кластеру с помощью следующей команды. # kubectl get nodes Если все шаги выполнены успешно, на главном узле должны быть показаны узлы 1 и 2 в состоянии готовности. На этом этапе мы успешно завершили установку кластера Kubernetes на Centos 7 и успешно взяли два рабочих узла. Теперь можно начинать создавать модули и разворачивать службы.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59