По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В сегодняшней статье покажем пример настройки DMVPN – Dynamic Multipoint VPN, что является VPN решением компании Cisco. Данное решение используется, когда требуется высокая масштабируемость и легкость настройки при подключении филиалов к головному офису.
DMPVN одно из самых масштабируемых и эффективных решений VPN поддерживаемых компанией Cisco. В основном оно используется при топологии Hub-and-Spoke, где вы хотели бы видеть прямые VPN туннели Spoke-to-Spoke в дополнение к обычным Spoke-to-Hub туннелям. Это означает, что филиалы смогут общаться с друг другом напрямую, без необходимости прохождение трафика через HQ. Как уже упоминали, эта технология является проприетарной технологией Cisco.
Если вам необходимо подключить более десяти сайтов к головному офису, то DMPVN будет идеальным выбором. Кроме того, DMPVN поддерживает не только Hub-and-Spoke, но и Full-Mesh топологию, так как все сайты имеют между собой связность без необходимости настройки статических VPN туннелей между сайтами.
Некоторые характеристики DMVPN
Для начала перечислим важные характеристики данного способа организации Site-to-Site VPN для лучшего понимания:
Центральный маршрутизатор (HUB) - данный роутер работает как DMVPN сервер, и Spoke маршрутизаторы работают как DMVPN клиенты;
У данного маршрутизатора есть публичный статический IP-адрес на WAN интерфейсе;
У Spoke маршрутизаторов на WAN интерфейсах может как статический, так и динамический публичный IP-адрес;
У каждого филиала (Spoke) есть IPSEC туннель к головному офису (Hub);
Spoke-to-Spoke - туннели устанавливаются при возникновении необходимости, когда есть движение трафика между филиалами. Таким образом, трафик может не ходить через головной офис, а использовать прямые туннели между филиалами;
Все туннели используют Multipoint GRE c IPSEC;
NHRP (Next Hop Resolution Protocol) - данный протокол используется для установления соответствий между приватными IP туннельных интерфейсов с публичными WAN адресами
Описанные выше NHRP соответствия будут храниться на NHRP сервере, чем в нашем случае является HUB роутер. Каждый филиал устанавливает соединение с головным офисом и регистрирует свой публичный IP-адрес и его приватный IP-адрес тунеля;
Когда филиалу необходимо отправить пакеты в подсеть другого филиала, он запрашивает NHRP сервер для получения информации о внешнем публичном адресе целевого филиала;
Для лучшей масштабируемости советуем использовать один из протоколов динамический маршрутизации между всеми роутерами – например, EIGRP;
Еще раз кратко о технологиях, которые использует DMVPN:
Multipoint GRE;
IPSEC;
NHRP – Next Hop Resolution Protocol;
Статическая или динамическая маршрутизация;
Настройка маршрутизатора
Конкретно в нашем примере у нас будет HUB маршрутизатор и два филиала. И, как было описано ранее, HUB – это DMVPN cервер, а филиалы – DMPVN клиенты.
В нашем примере в качестве маршрутизатора используется CISCO1921/K9
Сначала настраиваем HUB маршрутизатор – ему необходимо присвоить статический IP – адрес на внешнем WAN-интерфейсе:
! Настраиваем интерфейсы
interface GigabitEthernet0/0
description to Internet-WAN
ip address 10.10.10.1 255.255.255.252
!
interface GigabitEthernet0/1
description to LAN
ip address 192.168.160.1 255.255.255.0
duplex auto
! Настраиваем туннельный интерфейс, который является улучшенным GRE (Multipoint GRE)
interface Tunnel1
description DMVPN Tunnel
ip address 172.16.1.1 255.255.255.0 // выбираем приватную подсеть для туннелей
no ip redirects
ip nhrp authentication nhrp1234 // аутентификация между маршрутизаторами
ip nhrp network-id 1 // сетевой идентификатор, который должен быть одинаковым на всех маршрутизаторах
load-interval 30
keepalive 5 10
tunnel source GigabitEthernet0/0 // назначаем источником туннеля WAN интерфейс
tunnel mode gre multipoint // определяем туннель как mGRE
tunnel protection ipsec profile protect-gre // шифруем трафик в туннеле с помощью IPSEC
ip mtu 1440 // уменьшаем MTU для того, чтобы разрешить оверхед на mGRE и IPSEC
ip nhrp map multicast dynamic // разрешаем форвардить мультикаст трафик между туннелями.
! Настраиваем IPSEC на главном роутере
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key isakmp1234 address 0.0.0.0 0.0.0.0 // принимать соединения от любого источника при наличии динамических филиалов
!
crypto ipsec transform-set TS esp-3des esp-md5-hmac
mode tunnel
!
!
crypto ipsec profile protect-gre // профиль добавленный к mGRE туннелю для шифрования
set security-association lifetime seconds 86400
set transform-set TS
! Настраиваем статическую маршрутизацию на HUB маршрутизаторе
ip route 192.168.164.0 255.255.255.0 172.16.1.2 // удаленные подсети доступны через IP удаленного туннеля
ip route 192.168.161.0 255.255.255.0 172.16.1.3 // удаленные подсети доступны через IP удаленного туннеля
Затем настраиваем маршрутизаторы в филиалах (Spoke роутеры) - у одного маршрутизатора статический айпишник на WAN интерфейсе, и у другого динамический, получаемый по DHCP. Первый маршрутизатор в филиале, с динамическим IP:
interface GigabitEthernet0/0
description WAN to Internet
ip address dhcp
duplex auto
speed auto
interface GigabitEthernet0/1
description To LAN
ip address 192.168.164.1 255.255.255.0
duplex auto
speed auto
interface Tunnel1
ip address 172.16.1.2 255.255.255.0 // помещаем в ту же подсеть что и другие туннели
no ip redirects
ip nhrp map multicast dynamic // разрешаем форвардить мультикаст трафик между туннелями
tunnel source GigabitEthernet0/0 // “source”- WAN интерфейс
tunnel mode gre multipoint
tunnel protection ipsec profile protect-gre
ip nhrp authentication nhrp1234
ip nhrp map 172.16.1.1 10.10.10.1 // соответствие HUB адреса туннеля с HUB адресом WAN
ip nhrp network-id 1
ip nhrp nhs 172.16.1.1 // настройка NHRP
ip nhrp registration no-unique // если NHRP процесс завершился (поиск соответствия) для определенного IP, то больше данный процесс не запустится
ip nhrp map multicast 10.10.10.1 // Отправка milticast трафика только в Hub. Головной маршрутизатор будет получать весь мультикаст трафик (например, обновления протокола маршрутизации) и отправлять его всем Spoke маршрутизаторам
ip mtu 1440
load-interval 30
keepalive 5 10
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key isakmp1234 address 0.0.0.0 0.0.0.0 // Филиалы должны разрешать подклюения с любого адреса для формирования IPSEC VPN туннелей с другими филиалами
!
!
crypto ipsec transform-set TS esp-3des esp-md5-hmac
mode tunnel
!
crypto ipsec profile protect-gre
set security-association lifetime seconds 86400
set transform-set TS
ip route 192.168.160.0 255.255.255.0 172.16.1.1 // Маршрут для HUB
ip route 192.168.161.0 255.255.255.0 172.16.1.3 // Маршрут для другого филиала Spoke site
Второй филиальный маршрутизатор, со статическим IP:
interface GigabitEthernet0/0
description TO Internet
ip address 10.10.10.9 255.255.255.252
duplex auto
speed auto
interface GigabitEthernet0/1
description To: LAN
ip address 192.168.161.1 255.255.255.0
duplex auto
speed auto
interface Tunnel1
ip address 172.16.1.3 255.255.255.0 // должен быть в той же подсети что и другие туннели
no ip redirects
ip nhrp map multicast dynamic // разрешаем форвард мульткастов между туннелями.
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel protection ipsec profile protect-gre
ip nhrp authentication nhrp1234
ip nhrp map 172.16.1.1 10.10.10.1 // мапируем адрес HUB тунеля к WAN адресу
ip nhrp network-id 1
ip nhrp nhs 172.16.1.1 // настраиваем NHRP клиент с указанием адреса сервера
ip nhrp registration no-unique
ip nhrp map multicast 10.10.10.1
ip mtu 1440
load-interval 30
keepalive 5 10
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key isakmp1234 address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set TS esp-3des esp-md5-hmac
mode tunnel
!
!crypto ipsec profile protect-gre
set security-association lifetime seconds 86400
set transform-set TS
ip route 192.168.160.0 255.255.255.0 172.16.1.1 // маршрут до головного маршрутизатор
ip route 192.168.164.0 255.255.255.0 172.16.1.2 // маршрут до другого филиала
Переходим к тестированию:
show dmvpn // проверяем статус DMVPN и NHRP
show crypto isakmp sa // проверяем IPSEC cвязность между маршрутизаторами
ping 192.168.164.1 // пингуем для проверки
ping 192.168.1.1
В нашем примере использовалась статическая маршрутизация, но при большом количестве филиалов необходимо использовать протоколы динамический маршрутизации для уменьшения ручного труда и риска ошибки.
Теперь мы можем продолжить поиск и устранение неисправностей. В большинстве случаев вы ожидаете увидеть определенную сеть в таблице маршрутизации, но ее там нет. Далее рассмотрим несколько сценариев неправильной (или полностью не рабочей) работы EIGRP и как исправить наиболее распространенные ошибки. Ниже перечислены часто встречающиеся ошибки:
Первую часть статьи про траблшутинг EIGRP можно почитать здесь.
Кто-то настроил distribute-list, чтобы информация о маршрутах фильтровалась.
Было настроено автосуммирование или кто-то настроил суммирование вручную
Split-horizon блокирует объявление маршрутной информации.
Перераспределение было настроено, но информация из EIGRP не используется.
Перераспределение было настроено, но никакие внешние маршруты EIGRP не отображаются.
Case #1
Давайте начнем с простой топологии. OFF1 и OFF2 работают под управлением EIGRP, и каждый маршрутизатор имеет интерфейс обратной связи. Вот конфигурация обоих маршрутизаторов:
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
OFF1(config-router)#network 1.1.1.0 0.0.0.255
OFF1(config-router)#network 192.168.12.0 0.0.0.255
OFF2(config)#router eigrp 12
OFF2(config-router)#no auto-summary
OFF2(config-router)#network 2.2.2.0 0.0.0.255
OFF2(config-router)#network 192.168.12.0 0.0.0.255
Все работает нормально, пока через пару недель один из пользователей не пожаловался на то, что ему не удалось подключиться к сети 2.2.2.0 / 24 из-за OFF1. Посмотрите на таблицу маршрутизации на OFF1, и вот что вы видите:
По какой-то причине нет сети 2.2.2.0 / 24 в таблице маршрутизации.
Видно, что на OFF1 не настроен distribute lists.
OFF2 содержит сеть 1.1.1.0 / 24 в своей таблице маршрутизации. Давайте выполним быструю отладку, чтобы увидеть, что происходит.
Отладка показывает нам, что происходит. Прежде чем вы увидите это сообщение, придется немного подождать, или вы можете сбросить соседство EIGRP, чтобы ускорить процесс. Как видите, в сети 2.2.2.0 / 24 отказано из-за distribute list.
Другой быстрый способ проверить это - использовать команду show ip protocol.
В этом случае использование show run могло бы быстрее обнаружить distribute-list.
Вот список доступа, доставляющий нам неприятности.
OFF2(config)#router eigrp 12
OFF2(config-router)#no distribute-list 1 out
Удалим distribute-list.
Задача решена!
Извлеченный урок: если команды network верны, проверьте, есть ли у вас distribute-list, который запрещает объявлять префиксы или устанавливать их в таблицу маршрутизации.
Имейте в виду, distribute-list могут быть настроены как входящие или исходящие, как список доступа.
Case #2
В следующем сценарии те же 2 маршрутизатора, но разные сети в loopback. Вот конфигурация:
OFF1(config)#router eigrp 12
OFF1(config-router)#network 192.168.12.0
OFF1(config-router)#network 10.0.0.0
OFF2(config)#router eigrp 12
OFF2(config-router)#network 192.168.12.0
OFF2(config-router)#network 10.0.0.0
Как вы видите - это довольно базовая конфигурация.
Глядя на таблицы маршрутизации, не видно сети 10.1.1.0 / 24 или 10.2.2.0 / 24. Видна запись для сети 10.0.0.0/8, указывающую на интерфейс null0. Эта запись отображается только при настройке суммирования и используется для предотвращения циклов маршрутизации.
Давайте включим отладку и посмотрим, что мы можем найти.
OFF2#clear ip eigrp 12 neighbors
Этой командой мы сделаем сброс соседства EIGRP, чтобы ускорить процесс. Имейте в виду, что это, вероятно, не самое лучшее, что можно сделать в производственной сети, пока вы не узнаете, что не так, но это действительно помогает ускорить процесс.
Вот наш ответ. Отладка говорит нам, что сеть 10.2.2.0 / 24 не следует объявлять, а сеть 10.0.0.0 / 8 нужно объявлять (это вкратце). Это может произойти по двум причинам:
Суммирование было кем-то настроено
Авто-суммирование включено для EIGRP.
Как вы видите, авто-суммирование включено для EIGRP. В зависимости от версии IOS авто-суммирование включено или отключено по умолчанию.
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
OFF2(config)#router eigrp 12
OFF2(config-router)#no auto-summary
Отключение автоматического суммирования должно помочь.
Ну что, наши сети появились в таблице маршрутизации.
Извлеченный урок: если включена автоматическое суммирование EIGRP, вы можете столкнуться с нестабильными сетями.
Case #3
Очередная проблема. В приведенном выше примере у нас есть 2 маршрутизатора, но разные сети. OFF1 содержит сеть 172.16.1.0 / 24 на интерфейсе обратной связи, а OFF2 содержит сеть 172.16.2.0 / 24 и 172.16.22.0 / 24 на своих интерфейсах обратной связи. Посмотрим конфигурацию EIGRP обоих маршрутизаторов:
Как вы видите, что все сети объявляются. Обратите внимание, что в OFF1 включено автоматическое суммирование, а в OFF2 отключено автоматическое суммирование.
Кто-то настроил суммирование на OFF2 и отправляет ее на OFF1. Суммирование создана для сети 172.16.0.0 / 16.
Однако, если посмотреть на таблицу маршрутизации OFF1, она не появится. Мы видим запись для сети 172.16.0.0 / 16, но она указывает на интерфейс null0, а не на OFF2. Что здесь происходит?
OFF2#clear ip eigrp 12 neighbors
Давайте сделаем отладку на OFF2, чтобы увидеть, объявляется ли суммирование. Выполним команду clear ip eigrp neighbors, просто чтобы ускорить процесс.
Глядя на отладку, видно, что OFF2 работает правильно. Он объявляет сводный маршрут 172.16.0.0 / 16 так, как должен. Это означает, что проблема должна быть в OFF1.
Давайте проведем отладку OFF1.
Мы можем видеть, что OFF1 получает сводный маршрут от OFF2, но решает не использовать его.
Это хороший момент для проверки таблицы топологии EIGRP. Вы видите, что он имеет суммирование сети 172.16.0.0 / 16 от OFF2 в своей таблице топологии EIGRP, но OFF1 решает не использовать ее, потому что вход через интерфейс null0 является лучшим путем.
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
Решение состоит в том, что нам нужно избавиться от записи null0 в таблице маршрутизации. Единственный способ сделать это - отключить автоматическое суммирование.
Отключение автоматического суммирования удаляет запись null0, и теперь суммирование OFF2 установлено проблема решена!
Извлеченный урок: автоматическое суммирование EIGRP создает запись через интерфейс null0, которая может помешать установке суммирования, которые вы получаете от соседних маршрутизаторов.
Case #4
Есть еще одна проблема с суммированием, которую сейчас и разберем. Мы используем топологию, которую вы видите выше, и ниже конфигурация EIGRP обоих маршрутизаторов.
Все сети объявлены, и автоматическое суммирование отключено на обоих маршрутизаторах.
Суммирование было настроено на OFF2 и должно быть объявлено к OFF1.
К сожалению, ничего не видно на OFF1. Давайте проверим OFF2, чтобы посмотреть, что не так.
Когда дело доходит до устранения неполадок с сетью, вашими друзьями являются не Google или Яндекс, а команды Debug и show.
Странно, это единственная сеть, которую OFF2 объявляет.
Одно из золотых правил маршрутизации: вы не можете объявлять то, чего у вас нет. Очевидно, OFF2 знает только о сети 192.168.12.0 / 24.
Вот это ошибка! Кто-то выполнил команду отключения на интерфейсах обратной связи.
OFF2(config)#interface loopback 0
OFF2(config-if)#no shutdown
OFF2(config)#interface loopback 1
OFF2(config-if)#no shutdown
Включим интерфейсы.
Теперь мы видим, что суммирование объявляется.
Теперь мы видим суммирование в таблице маршрутизации OFF1- проблема решена!
Извлеченный урок: вы не можете объявлять то, чего у вас нет в таблице маршрутизации.
ВАЖНО. Последняя проблема может быть показаться простой, но есть важный момент, который вы не должны забывать: для объявления итогового маршрута в таблице маршрутизации объявляемого маршрутизатора должен быть указан хотя бы один префикс, попадающий в итоговый диапазон!
Case #5
Давайте посмотрим на другую топологию. На рисунке выше у нас есть концентратор Frame Relay и соответствующая топология. Каждый из OFF1 и OFF2 имеет интерфейс обратной связи, который мы будем объявлять в EIGRP. Вот соответствующая конфигурация всех маршрутизаторов:
CONC(config)#router eigrp 123
CONC(config-router)#no auto-summary
CONC(config-router)#network 192.168.123.0
OFF1(config-if)#router eigrp 123
OFF1(config-router)#no auto-summary
OFF1(config-router)#network 192.168.123.0
OFF1(config-router)#network 2.2.2.0 0.0.0.255
OFF2(config)#router eigrp 123
OFF2(config-router)#no auto-summary
OFF2(config-router)#network 192.168.123.0
OFF2(config-router)#network 3.3.3.0 0.0.0.255
Видно, что все сети объявлены.
Наш концентратор-маршрутизатор видит сети из двух OFF-маршрутизаторов.
К сожалению, наши маршрутизаторы не видят ничего ...
Похоже, что маршрутизатор-концентратор не объявляет сети, которые он изучает с помощью OFF-маршрутизаторов. Давайте включим отладку, чтобы увидеть, что происходит.
CONC#clear ip eigrp 123 neighbors
Сбросим соседство EIGRP, чтобы ускорить процесс.
В отладке мы видим, что наш маршрутизатор-концентратор узнает о сети 2.2.2.0 / 24 и 3.3.3.0 / 24, но объявляет только сеть 192.168.123.0 / 24 для OFF-маршрутизаторов. Разделение горизонта не позволяет размещать объявление от одного маршрутизатора на другой.
CONC(config)#interface serial 0/0
CONC(config-if)#no ip split-horizon eigrp 123
Давайте отключим разделение горизонта на последовательном интерфейсе маршрутизатора-концентратора.
Теперь мы видим, что маршрутизатор-концентратор объявляет все сети.
OFF-маршрутизаторы теперь могут узнавать о сетях друг друга, поскольку split horizon отключено. Это хорошо, но это еще не все.
Извлеченный урок: RIP и EIGRP являются протоколами маршрутизации на расстоянии и используют split horizon. Split horizon предотвращает объявление префикса вне интерфейса, на котором мы его узнали.
Хотя сети отображаются в таблицах маршрутизации мы не можем пропинговать от одного OFF-маршрутизатора к другому. Это не проблема EIGRP, но она связана с Frame Relay. Мы должны это исправить.
Когда OFF1 отправляет IP-пакет на OFF2, IP-пакет выглядит следующим образом:
Давайте пока подумаем, как роутер, и посмотрим, что здесь происходит. Сначала нам нужно проверить, знает ли OFF1, куда отправить 3.3.3.3:
Существует запись для 3.3.3.3, а IP-адрес следующего перехода - 192.168.123.1 (маршрутизатор-концентратор). Можем ли мы достичь 192.168.123.1?
Нет проблем, кажется, OFF1 может пересылать пакеты, предназначенные для сети 3.3.3.0/24. Давайте перейдем к маршрутизатору CONC.
У маршрутизатора-концентратора нет проблем с отправкой трафика в сеть 3.3.3.0 / 24, поэтому на данный момент мы можем сделать вывод, что проблема должна быть в маршрутизаторе OFF2.
Это IP-пакет, который получает маршрутизатор OFF2, и когда он отвечает, он создает новый IP-пакет, который выглядит следующим образом:
Способен ли OFF2 достигать IP-адрес 192.168.123.2 Давайте узнаем!
Теперь мы знаем проблему ... OFF2 не может достичь IP-адреса 192.168.123.2
Если мы посмотрим на таблицу маршрутизации OFF2, то увидим, что сеть 192.168.123.0 / 24 подключена напрямую. С точки зрения третьего уровня у нас нет никаких проблем. Пришло время перейти вниз по модели OSI и проверить уровень 2 ... или, может быть, между уровнем 2 и 3.
Frame Relay использует Inverse ARP для привязки уровня 2 (DLCI) к уровню 3 (IP-адрес). Вы можете видеть, что нет сопоставления для IP-адреса 192.168.123.2.
OFF2(config)#int s0/0
OFF2(config-if)#frame-relay map ip 192.168.123.2 301
Давайте frame-relay map сами.
Теперь роутер OFF2 знает, как связаться с роутером OFF1
Наконец, маршрутизатор OFF1 может пропинговать интерфейс обратной связи маршрутизатора OFF2. Когда мы пытаемся пропинговать от маршрутизатора OFF2 к интерфейсу обратной связи маршрутизатора OFF1, у нас возникает та же проблема, поэтому мы также добавим туда оператор frame-relay map:
OFF1(config)#int s0/0
OFF1(config-if)#frame-relay map ip 192.168.123.3 201
Теперь у нас есть extra frame-relay map на маршрутизаторе OFF1.
И наш пинг проходит!
В одной из вышедших ранее статей мы разбирали такой инструмент сетевого администратора, как 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 высокую репутацию, и позволяет с уверенностью сказать, что данный продукт имеет высокое качество.