Поставщики инфраструктуры коммутаторов лидируют в открытии широкого набора возможностей для сетевых инженеров. Сетевая автоматизация, или сетевые сценарии, объединяет функциональность устройств сетевой инфраструктуры с простыми сценариями, которые позволяют сетевым инженерам выходить за рамки пассивного сетевого мониторинга и посмертного анализа к адаптивным сетям в реальном времени. Вопрос в том, будет ли это работать и как вы можете использовать его на практике?
Поставщики инфраструктуры коммутаторов лидируют в открытии широкого набора возможностей для сетевых инженеров. Сетевая автоматизация, или сетевые сценарии, объединяет функциональность устройств сетевой инфраструктуры с простыми сценариями, которые позволяют сетевым инженерам выходить за рамки пассивного сетевого мониторинга и посмертного анализа к адаптивным сетям в реальном времени. Вопрос в том, будет ли это работать и как вы можете использовать его на практике?
Как и все хорошее, сетевая автоматизация возникла во время набега на нечто совершенно иное. Я намеревался написать о захвате сетевых пакетов и некоторых инструментах и методах, которые вы можете использовать для сбора дополнительной информации о своей сети, для устранения проблем и, наконец, для того, чтобы прекратить показывать пальцем при возникновении проблемы. Когда я начал думать о первом шаге в этом процессе, а именно о сборе самих пакетов, я потратил некоторое время на размышления о проблемах, с которыми вы столкнетесь на этом пути. Главная среди этих проблем заключается в том, что, если вы уже не инвестировали в огромную инфраструктуру сбора трафика или не используете аналитическую компанию, у вас, вероятно, не будет захвата трафика, который вам нужен, когда они вам понадобятся. Без этих захватов обсуждение анализа на уровне пакетов - спорный вопрос.
Это привело меня к размышлениям о том, как и где можно выполнять триггерный захват пакетов на основе сетевых событий и как можно автоматизировать этот процесс. Появились сценарии Cisco Tclsh и сценарии автоматизации сети, которые она называет встроенным управлением событиями, вместе с миром возможностей, о существовании которых, как мне кажется, большинство инженеров не подозревает.
Во-первых, позвольте мне сказать, что это новая область для меня, и я занят тестированием, но на первый взгляд многие поставщики коммутаторов осознали, что сетевым инженерам нужна способность работать как инженеры-программисты, чтобы справиться со скоростью изменения в их сетях. Под этим я подразумеваю, что инженеры должны иметь возможность взять свою интеллектуальную собственность, опыт, который делает их эффективными, и объединить их в воспроизводимый самородок, который распространяется в их среде и сразу же добавляет ценность.
Хотите пример этого? Предположим, что у вас есть сетевой интерфейс, обслуживающий удаленный розничный филиал, и что каждые несколько дней ссылка привязана к 100-процентному использованию, и пользователи жалуются на время отклика приложений. У вас есть несколько вариантов сбора данных, чтобы справиться с этой ситуацией. На самом базовом уровне вы можете использовать программное обеспечение и технологии для мониторинга пропускной способности, такие как NetFlow, чтобы узнать «что» и «когда» этой перегрузки. Но хотя NetFlow - отличный пакет для учета трафика, он не позволяет вам видеть детали TCP или UDP-диалога, и дьявол всегда кроется в деталях.