Метка «networking»

Автор: Piotr Siwczak

За последнее время сети в OpenStack прошли эволюцию от простой, едва ли пригодной к использованию модели к более совершенной с возможностью полной изоляции владельцев. Поддержка различных требований пользователей в OpenStack реализована с помощью т.н. “сетевых менеджеров”. Сетевой менеджер определяет сетевую топологию конкретного деплоймента OpenStack. Начиная с версии Essex, пользователь может выбрать один из трех вариантов сетевых менеджеров: FlatManager, FlatDHCPManager, VlanManager. В этой части статьи мы рассмотрим первые два, для последнего будет отведена вторая часть.

У менеджеров FlatManager и FlatDHCPManager есть много общего. Оба они основываются на концепции сетевых мостов (bridged networking) с использованием одного моста. В качестве примера рассмотрим сеть, состоящую из нескольких узлов.Читать полностью »

При построении сетей есть две конкурирующие топологии: это звезда (разных вариантов) и кольцо (разных вариантов). У звезды одно преимущество – низкая переподписка. Недостатки звезды — сложная структура, а соответственно сложность эксплуатации и высокая стоимость. Звезда — это решение для собранных в одно место пользователей на доступе: классическая сеть здания управления в предприятии, но не всегда и даже в этом случае. Ведь опорная сеть здания с соблюдением норм пожарной безопасности всегда будет прокладываться через два кабельных стояка в разных частях здания и это снова – кольцо, а не звезда: одно кольцо/жгут оптики через эти два стояка и два центра ядра сети здания/ЦОД.

Выбор конкретной топологии решения зависит от объекта и его особенностей. Кольцо всегда более выгодно для распределенных сетей, так как сделать звезду на большую распределенную сеть очень и очень дорого и в реальности практически невозможно. Поэтому кольцевая топология — это оптимальная топология для крупных предприятий, перерабатывающих заводов, городских сетей, сетей масштабов страны.

Кольцо и звезда: кто кого?

Рис. 1. Модуль АСУТП завода.

Читать полностью »

Редко, но метко в моей практике возникает задача, когда нужно быстро поднять сервер с «белым ip» для демонстрации результатов работы или просто для целей тестирования нового функционала перед выкатыванием его в продакшен. Каждый раз арендовать VDS для этого накладно, а связываться с облаками для подобных целей мне не хочется.

Поскольку локально я располагаю достаточным количеством практически даровых ресурсов, то мне нужно организовать временный сервер локально, а ip адрес прокинуть с любого внешнего сервера.
Читать полностью »

Доброго времени суток. Решил поделиться с вами своим пониманием этого вопроса, и механизма его решения, используемого в устройствах WAN оптимизации Silver Peak.

Итак, практическое большинство современных сетей, использует в своей основе пакетную передачу и протокол IP. Информация передается через сеть кусочками информации, и обычно размер этих кусочков варьируется от 1 байта до 1500 байт (Я имею ввиду полезную нагрузку). По пути через WAN сеть, такие пакеты могут пройти через великое множество маршрутизаторов и шлюзов. Некоторые из этих перевалочных пунктов вы можете увидеть при помощи утилиты Traceroute. Но это далеко не все реальные транзитные узлы, например вы не увидите здесь те узлы, через которые трафик прошел туннелированным (MPLS VPN, GRE и т.д.). При этом, с ненулевой долей вероятности, какой-нибудь из транзитных узлов будет в данный момент сильно загружен, и уничтожит ваш пакет, чтобы не допускать перегрузки сети. И чем больше таких транзитных узлов, тем больше вероятность потери пакета в сети.
Читать полностью »

Пролог

Недавно я столкнулся с необходимостью эффективной работы с сокетами в Windows приложении. Задача типичная для нагруженного сервера. Нетипичным тут будет казаться только язык реализации — Delphi.
Я хочу описать способ массовой асинхронной работы с большим количеством сокетов с использованием I/O Completion Ports. Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js