По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В одной из вышедших ранее статей мы разбирали такой инструмент сетевого администратора, как Chef. В этой статье мы рассмотрим конкретные примеры использования Chef на примерах компаний, применяющих это решение в своей деятельности.
Для начала, вспомним, что же это такое. Chef это система конфигурирования сети, то есть программа, работающая на клиент-серверной архитектуре, предназначенная для быстрого развертывания, управления, сбора данных, анализа и оптимизации компьютерной сети. Инструментарий Chef позволяет сделать настройку более оперативной, за счет горизонтального масштабирования сети. Также при помощи Chef можно подготовить несколько сценариев управления сетью, что позволяет решить большинство задач, возникающих перед современной командой сетевых инженеров в крупной корпорации
Одним из ярких примеров применения Chef для расширения деятельности компаний является южноафриканский Standard Bank. С расширением его деятельности возникла проблема замедления работы системы, в связи с тем, что у компании появилось слишком много хранилищ данных. Это делало систему управления сетью достаточно громоздкой и неповоротливой, поэтому руководство организации решилось на внедрение системы Chef. Это решение позволило повысить эффективность развертывания сети, а также решило проблему медленной работы. Сетевые инженеры разработали несколько сценариев работы сети, и выбрали основную "поваренную книгу" и несколько резервных на случай возникновения нештатных ситуаций. В результате Standard Bank до сих пор удерживает позиции в верхней половине финансовых организаций, действующих на развивающихся рынках.
Также интересен опыт применения Chef в компании Rakuten создателях популярного мессенджера Viber. В своё время здесь столкнулись с проблемой низкой эффективности в работе серверов связи, основанной на различных программных средах на клиентских устройствах. Последовательное внедрение автоматизации посредством применения Chef позволило привести работу серверов к единообразию, что позволило не только решить существующую проблему, но и существенно повысило скорость работы сервиса и удобство связи. Это позволяет до сих пор считать продукт компании Rakuten одним из самых популярных на рынке.
Всем известен такой гигант IT-индустрии, как IBM. Эта гигантская корпорация часто выступает в качестве спонсора крупных спортивных соревнований, а также предоставляет для них информационную поддержку. В ходе освещения спортивных событий на своих сайтах, компания столкнулась с чрезвычайной нагрузкой на свои сервера. Это приводило к задержкам и неполадкам в работе. Специалисты компании применили решение Chef для того, чтобы оперативно увеличить количество серверов, распределив обработку информации между ними. Это решение настолько пришлось по душе руководству компании IBM, что обе компании до сих пор поддерживают партнерские отношения, а IBM поддерживает развитие проекта Chef.
Корпорация Facebook является примером взрывного роста популярности социальных сетей. Различными сервисами от этой компании пользуются сотни миллионов людей по всему миру. И более десятка лет обслуживание серверов осуществлялось с помощью одного и того же движка. Кластерная структура сети Facebook насчитывала по десятку тысяч устройств в одном кластере. И расширение сервиса с течением времени привело к тому, что техническое решение по обслуживанию серверов сети было признано устаревшим. Технический отдел компании оценил гибкость решения Chef и скорость его работы, и было решено применить эту систему для обслуживания серверов компании, что обеспечило выравнивание темпов роста сети. С применением Chef на текущий момент компания имеет серверные мощности, чтобы обеспечить обслуживание не только существующих клиентов, но и привлечение новых.
В небольших компаниях, которые насчитывают несколько сотен рабочих станций, Chef также подтверждает свою эффективность. Конечно, есть варианты нанять нескольких сотрудников для оперативного обслуживания сети, мониторинга, расширения и сбора данных, однако на деле многие компании предпочитают иметь дело с одним-двумя администраторами сети, хорошо владеющими своим инструментом. Поскольку Chef в умелых руках - универсальный инструмент.
Таким образом, очевидно, что технология Chef опробована и одобрена по-настоящему серьезными компаниями. Это обеспечивает команде разработчиков Chef высокую репутацию, и позволяет с уверенностью сказать, что данный продукт имеет высокое качество.
Всем привет! На IP-телефонах Cisco, которые зарегистрированы на Cisco Unified Communications Manager (CUCM) , можно просматривать статусные сообщения о состоянии телефона и сетевую статистику в реальном времени. Эта информация доступна с самого телефона и может быть полезна при траблшутинге системы.
/p>
Для доступа к статусным сообщениям нужно на IP-телефоне Cisco нажать физическую кнопку Settings, далее в меню настроек выбрать Status (Состояние) и затем нажать Status Messages (Сообщения о состоянии). Сообщение отображается вместе со временем его появления.
Сообщение Описание
BootP server used Информационное сообщение, телефон получил IP адрес через BootP сервер, а не через DHCP сервер
File auth error Произошла ошибка, когда телефон пытался проверить подписанный файл. Это сообщение содержит имя файла, с которым возникла проблема. Вероятная проблема – файл поврежден, необходимо удалить и добавить заново телефон через Cisco Unified Communications Manager Administration tool. Либо это проблема с CTL файлом и в этом случае нужно запустить CTL клиент и обновить CTL файл, убедившись, что в него включены необходимые TFTP серверы.
CFG file not found Именной файл конфигурации и файл конфигурации по умолчанию не был найден на TFTP сервере. Файл конфигурации для определенного телефона создается при добавлении телефона в базу данных CUCM. Если телефон не был добавлен в базу данных, то TFTP-сервер генерирует ответ CFG File Not Found.
CFG TFTP Size Error Конфигурационный файл слишком большой для файловой системы телефона. Нужно перезагрузить телефон.
Checksum Error Скачанный файл ПО поврежден. Необходимо скачать новую копию файла прошивки телефона и поместить его в каталог TFTP.
DHCP timeout DHCP сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между DHCP сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам DHCP сервер (проверить его конфигурацию).
DNS timeout DNS сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между DNS сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам DNS сервер (проверить его конфигурацию).
DNS unknown host DNS не смог разрешить имя TFTP сервера или CUCM. Необходимо убедиться, что имена хостов TFTP сервера или CUCM настроены правильно в DNS или использовать IP-адреса вместо имен хостов.
Duplicate IP Другое устройство уже использует IP адрес, который присвоен телефону. Если телефону присвоен статический адрес, то нужно проверить, что ни у какого другого устройства нет такого же адреса, а если используется DHCP, то следует проверить конфигурацию DHCP сервера.
Error update locale Один или более файлов локализаций не был найден в директории TFTP или файл оказался не валидным, и локализация не была изменена. Необходимо убедиться что следующие файлы находятся в поддиректориях TFTP сервера: tones.xml, glyphs.xml, dictionary.xml, kate.xml
IP address released Телефон остается в режиме ожидания пока не включится питание или пока DHCP адрес не будет сброшен.
Load ID incorrect Load ID программного обеспечения неправильного типа. Нужно проверить Load ID, назначенный телефону (во вкладке Device - Phone) и убедиться, что он введен правильно.
Load rejected HC Загруженное приложение несовместимо с аппаратным обеспечением телефона. Эта ошибка возникает, когда происходит попытка установить на телефоне версию ПО, которое не поддерживает аппаратные изменения на этом телефоне.
No default router В DHCP или статической конфигурации не указан default router. Если телефон имеет статические адреса, то необходимо проверить что default router был указан, а если используется DHCP, то нужно проверить его конфигурацию.
No DNS server IP В DHCP или статической конфигурации не указан адрес DNS сервер. Нужно проверить что он указан на телефоне или на DHCP сервера.
Programming error Произошла ошибка во время программирования телефона. Нужно попробовать перезагрузить телефон и если проблема не устранится, то обратиться в службу техподдержки Cisco.
XmlDefault.cnf.xml, or .cnf.xml corresponding to the phone device name Информационное сообщение с указанием имени конфигурационного файла.
TFTP access error TFTP сервер указывает на директорию, которая не существует. Необходимо проверить что у DHCP сервера или телефона правильно указан адрес TFTP.
TFTP file not found Запрашиваемый файл (.bin) не найден в директории TFTP. Нужно проверить, что Load ID присвоен телефону (во вкладке Device - Phone) и что директория TFTTP сервера содержит .bin файл с этим идентификатором загрузки в качестве имени.
TFTP server not authorized Указанный TFTP-сервер не может быть найден в CTL телефона. Это может быть по нескольким причинам: DHCP-сервер настроен неправильно и не обслуживает правильный адрес сервера TFTP, если телефон использует статический IP-адрес, телефон может быть настроен с неправильным адресом сервера TFTP или если адрес сервера TFTP верен, может возникнуть проблема с файлом CTL (в этом случае нужно запустить CTL клиент и обновить CTL файл).
TFTP timeout TFTP сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между TFTP сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам TFTP сервер (проверить его конфигурацию).
Теперь рассмотрим меню сетевой статистики. Чтобы попасть в него нужно на IP-телефоне Cisco нажать физическую кнопку Settings, далее в меню настроек выбрать Status (Состояние) и Netwkork Statistics (Статистика сети).
Там можно увидеть следующие поля
Поле Описание
Rcv (Rx Frames) Количество пакетов, полученных телефоном
Xmt Frames (Tx Frames) Количество пакетов, отправленных телефоном
REr (Rx Broadcasts) Количество broadcast пакетов, полученных телефонном
BCast Количество broadcast пакетов, отправленных телефонном
Phone Initialized Сколько времени прошло с момента инициализации телефона
Elapsed Time Сколько времени прошло с момента перезагрузки телефона
Port 1 Состояние PC порта телефона (скорость и дуплекс)
Port 2 Состояние Network порта
В статье рассматриваются примеры протоколов, обеспечивающих Interlayer Discovery и назначение адресов. Первую часть статьи про Interlayer Discovery можно прочитать тут.
Domain Name System
DNS сопоставляет между собой человекочитаемые символьные строки, такие как имя service1. exemple, используемый на рисунке 1, для IP-адресов. На рисунке 3 показана основная работа системы DNS.
На рисунке 3, предполагая, что нет никаких кэшей любого вида (таким образом, весь процесс проиллюстрирован):
Хост A пытается подключиться к www.service1.example. Операционная система хоста проверяет свою локальную конфигурацию на предмет адреса DNS-сервера, который она должна запросить, чтобы определить, где расположена эта служба, и находит адрес рекурсивного сервера. Приложение DNS операционной системы хоста отправляет DNS-запрос на этот адрес.
Рекурсивный сервер получает этот запрос и - при отсутствии кешей - проверяет доменное имя, для которого запрашивается адрес. Рекурсивный сервер отмечает, что правая часть имени домена именуется example, поэтому он спрашивает корневой сервер, где найти информацию о домене example.
Корневой сервер возвращает адрес сервера, содержащий информацию о домене верхнего уровня (TLD) example.
Рекурсивный сервер теперь запрашивает информацию о том, с каким сервером следует связаться по поводу service1.example. Рекурсивный сервер проходит через доменное имя по одному разделу за раз, используя информацию, обнаруженную в разделе имени справа, чтобы определить, какой сервер следует запросить об информации слева. Этот процесс называется рекурсией через доменное имя; следовательно, сервер называется рекурсивным сервером.
Сервер TLD возвращает адрес полномочного сервера для service1.example. Если информация о местонахождении службы была кэширована из предыдущего запроса, она возвращается как неавторизованный ответ; если фактический сервер настроен для хранения информации об ответах домена, его ответ является авторитетным.
Рекурсивный сервер запрашивает информацию о www.service1.example у полномочного сервера.
Авторитетный сервер отвечает IP-адресом сервера B.
Рекурсивный сервер теперь отвечает хосту A, сообщая правильную информацию для доступа к запрошенной службе.
Хост A связывается с сервером, на котором работает www.service1.example, по IP-адресу 2001:db8:3e8:100::1.
Этот процесс может показаться очень затяжным; например, почему бы просто не сохранить всю информацию на корневом сервере, чтобы сократить количество шагов? Однако это нарушит основную идею DNS, которая заключается в том, чтобы держать информацию о каждом домене под контролем владельца домена в максимально возможной степени. Кроме того, это сделало бы создание и обслуживание корневых серверов очень дорогими, поскольку они должны были бы иметь возможность хранить миллионы записей и отвечать на сотни миллионов запросов информации DNS каждый день. Разделение информации позволяет каждому владельцу контролировать свои данные и позволяет масштабировать систему DNS.
Обычно информация, возвращаемая в процессе запроса DNS, кэшируется каждым сервером на этом пути, поэтому сопоставление не нужно запрашивать каждый раз, когда хосту необходимо достичь нового сервера.
Как обслуживаются эти таблицы DNS? Обычно это ручная работа владельцев доменов и доменов верхнего уровня, а также пограничных провайдеров по всему миру. DNS не определяет автоматически имя каждого объекта, подключенного к сети, и адрес каждого из них.
DNS объединяет базу данных, обслуживаемую вручную, с распределением работы между людьми, с протоколом, используемым для запроса базы данных; следовательно, DNS попадает в базу данных сопоставления с классом протоколов решений. Как хост узнает, какой DNS-сервер запрашивать? Эта информация либо настраивается вручную, либо изучается с помощью протокола обнаружения, такого как IPv6 ND или DHCP.
DHCP
Когда хост (или какое-либо другое устройство) впервые подключается к сети, как он узнает, какой IPv6-адрес (или набор IPv6-адресов) назначить локальному интерфейсу? Одним из решений этой проблемы является отправка хостом запроса в какую-либо базу данных, чтобы определить, какие адреса он должен использовать, например DHCPv6. Чтобы понять DHCPv6, важно начать с концепции link local address в IPv6. При обсуждении размера адресного пространства IPv6, fe80:: / 10 был назван зарезервированным для link local address. Чтобы сформировать link local address, устройство с IPv6 объединяет префикс fe80:: с MAC (или физическим) адресом, который часто форматируется как адрес EUI-48, а иногда как адрес EUI-64. Например:
Устройство имеет интерфейс с адресом EUI-48 01-23-45-67-89-ab.
Этот интерфейс подключен к сети IPv6.
Устройство может назначить fe80 :: 123: 4567: 89ab в качестве link local address и использовать этот адрес для связи с другими устройствами только в этом сегменте.
Это пример вычисления одного идентификатора из другого. После того, как link local address сформирован, DHCP6 является одним из методов, который можно использовать для получения уникального адреса в сети (или глобально, в зависимости от конфигурации сети). DHCPv6 использует User Datagram Protocol (UDP) на транспортном уровне. Рисунок 4 иллюстрирует это.
Хост, который только что подключился к сети, A, отправляет сообщение с запросом. Это сообщение поступает с link local address и отправляется на multicast address ff02 :: 1: 2, порты UDP 547 (для сервера) и 546 (для клиента), поэтому каждое устройство, подключенное к одному и тому же физическому проводу, получит сообщение. Это сообщение будет включать уникальный идентификатор DHCP (DUID), который формирует клиент и использует сервер, чтобы обеспечить постоянную связь с одним и тем же устройством.
B и C, оба из которых настроены для работы в качестве серверов DHCPv6, отвечают рекламным сообщением. Это сообщение является одноадресным пакетом, направленным самому A с использованием link local address, из которого A отправляет запрашиваемое сообщение.
Хост A выбирает один из двух серверов, с которого запрашивать адрес. Хост отправляет запрос на multicast address ff02 :: 1: 2, прося B предоставить ему адрес (или пул адресов), информацию о том, какой DNS-сервер использовать, и т. д.
Сервер, работающий на B, затем отвечает ответом на изначально сформированный link local address A; это подтверждает, что B выделил ресурсы из своего локального пула, и позволяет A начать их использование.
Что произойдет, если ни одно устройство в сегменте не настроено как сервер DHCPv6? Например, на рисунке 4, что, если D - единственный доступный сервер DHCPv6, потому что DHCPv6 не работает на B или C? В этом случае маршрутизатор (или даже какой-либо другой хост или устройство) может действовать как ретранслятор DHCPv6. Пакеты DHCPv6, которые передает A, будут приняты ретранслятором, инкапсулированы и переданы на сервер DHCPv6 для обработки.
Примечание. Описанный здесь процесс называется DHCP с отслеживанием состояния и обычно запускается, когда в объявлении маршрутизатора установлен бит Managed. DHCPv6 может также работать с SLAAC, для предоставления информации, которую SLAAC не предоставляет в режиме DHCPv6 без сохранения состояния. Этот режим обычно используется, когда в объявлении маршрутизатора установлен бит Other. В тех случаях, когда сетевой администратор знает, что все адреса IPv6 будут настроены через DHCPv6, и только один сервер DHCPv6 будет доступен в каждом сегменте, сообщения с объявлением и запросом можно пропустить, включив быстрое принятие DHCPv6.
А теперь почитайте про Address Resolution Protocol - протокол разрешения IPv4-адресов