Проектирование и моделирование сетей связи в системе Riverbed Modeler
.pdf
Рисунок 2.3 – Параметры объекта «сегмент сети»
2.3 Моделирование сети
Предположим, что нам необходимо оценить характеристики сети за десять минут. Для этого нужно выполнить следующие действия:
1. Нажать на кнопку Configure/Run Discrete Event
Simulation. 
2. Установить длительность прогона Duration на 10 минут.
3. Нажать Run.
4. После завершения прогона нажать Close.
Просмотр времени отклика приложения Oracle для пользователей на этажах 1, 5 и 10 выполняется следующим образом:
1. Нажать правой кнопкой мыши на объекте < 95 Users Floor 10> и выберите View Results.
41
2. Развернуть Client DB Query и выбрать Response Time (sec.) и нажать Show (рисунок 2.4).
3. Закрыть окно View Results.
4. Нажать правой кнопкой мыши на объекте « 50 Users Floor 5» и выбрать View Results.
5. Развернуть Client DB Query и выбрать Response Time (sec.).
6. Нажать Add и на графическую панель первого графика (это делается для отображения статистики для пользователей на различных этажах на одной и той же панели).
7. Повторить шаги с 5 по 7 для того, чтобы добавить к графику время отклика приложения для пользователей н а этаже 1.
Рисунок 2.4 – Результаты моделирования
Замечание. Кнопка Hide/Show Graph Panels
позволяет спрятать/показать графики.
Теперь имеются статистики для пользователей на всех этажах на одном и том же графике.
42
Рисунок 2.5 – Сравнительные результаты
Анализ полученных результатов
Время отклика (Response Time)_ приложения близко к 0,007 секундам для пользователей на 10 -м этаже. Оно уменьшается по мере продвижения к нижним этажам. Пользователи на 1-м этаже имеют наименьшее время отклика. Это и есть величина задержки, вносимой коммутаторами.
Пользователи с самого верхнего этажа имеют высокие значения времени отклика приложения. Поэтому компания решила снизить это время путем перемещения центрального коммутатора и серверов на пятый этаж. Для этого необходимо выбрать Scenarios -> Switch To Scenario -> Daisy_Chain_Network_Server_On_Fifth_Floor .
Компания реструктурирует сеть без дополнительных аппаратных средств для достижения лучшей производительности приложений для пользователей на верхних этажах.
Запустите заново прогон модели на десять минут, чтобы
43
увидеть, получили ли пользователи на 10 -м этаже лучшее время отклика.
Теперь сравним время отклика приложения для пользователей на разных этажах. Ожидается, что реструктурирование сети должно уменьшить врем я отклика для пользователей на верхних этажах. Для сравнения необходимо:
1. Нажать правой кнопкой мыши на объекте < 95 Users Floor 10> и выберите View Results.
2. Развернуть Client DB Query и выбрать Response Time (sec.) и нажать Show (рисунок 2.6).
3. Закрыть окно View Results.
4. Повторить шаги для «50 Users Floor 5» и «70 Users Floor 1».
Рисунок 2.6 – Сравнение результатов
44
Рисунок 2.7 – Полученные результаты
Как и ожидалось, время отклика приложения Oracle понижается для пользователей на этажах 5 и 10. Но пользователи на 1-м этаже будут наблюдать увеличение времени отклика.
Компания решает изменить архитектуру с
последовательной цепи к сети с жесткой магистральной
архитектурой в надежде поддержки приложений для всех пользователей. Для моделирован ия этого сценария необходимо выбрать Scenario -> Switch To Scenario -> Collapsed_Backbone-Network.
45
Рисунок 2.8 – Сеть с магистральной архитектурой
Затем необходимо запустить прогон сценария, чтобы оценить работу сети. Для этого необходимо сравнить времена отклика для всех 3 сценариев. Это поможет выявить наилучшую архитектуру для данного типа сети.
46
Рисунок 2.9 – Сравнение результатов
2.4 Выводы по лабораторной работе
1. Лабораторная работа посвящена оценке производительности приложений двух раз личных сетевых архитектур: «последовательная сеть» и «жесткая магистральная сеть». Показано, как можно изменить производительность сети и время отклика приложений в зависимости от архитектуры самой сети.
2. Рассмотрены сети данных с магистральной
архитектурой, |
в |
которой |
имеется |
центральный |
|
|
|
|
47 |
коммутатор в монтажной комнате для оборудования.
Время |
задержки, |
вводимое |
|
подсоединением |
||
дополнительных |
коммутаторов, |
в |
сценарии |
1 |
||
(коммутаторы на каждом этаже последовательно подсоединены к центральному коммутатору в по двале) для пользователей самого верхнего этажа увеличивается. Время отклика приложения близко к 0,007 секундам д ля пользователей на 10-м этаже и уменьшается по мере продвижения к нижним этажам (около 0,004 секунд на пятом этаже и менее 0,003 секунд на пер вом этаже). Пользователи на 1-м этаже имеют наименьшее время отклика. Это и есть величина задержки, вносимой коммутаторами.
3. В сценарии 2 топология последовательной цепи сохранена, но центральный коммутатор перемещен из подвала на пятый этаж. Это уменьш ило время задержки на самом верхнем этаже, но увеличило его на самом нижнем, а именно на 10 этаже порядка 0,005 секунд, на пятом этаже около 0,002 секунд и менее 0,005 секунд на первом этаже.
4. В сценарии 3 центральный коммутатор находится в подвале, но применена топология жесткой магистральной архитектуры, в которой центральный коммутатор подсоединяется напрямую к коммутаторам рабочих групп на каждом этаже. Полученные результаты таковы: на 1, 5 и 10 этажах задержка менее 0,002 с.
48
3 ПРОЕКТИРОВАНИЕ И ОПТИМИЗАЦИЯ СЕТИ
3.1 Содержание лабораторной работы
Настоящая лабораторная работа демонстрирует особенности проектирования сети, принимая во внимание пользователей, услуги и размещение узлов. Главной задачей является оптимизация схемы сети. Для анализа концептуальной схемы сети, обычно используют имитационное моделирование. Изначальная концептуальная конструкция обычно изменятся несколько раз, пока не будет принято конечное решение о том, какую схему следует внедрить. Желательно получить такую конструкцию, которая максимизирует производительность сети, принимая во внимание затраты и требуемые услуги, которые могут быть предложены пользователям различных типов. После того, как сеть внедрена, нужно периодически производить оптимизацию сети, чтобы удостовериться, что она обеспечивает максимальную производительность.
В этой лабораторной работе нужно спроектировать сеть для компании, которая имеет четыре отдела :
исследовательский, инженерный, коммерческий и отдел
продаж. Будет использована такая модель ЛВС, которая позволит рассмотреть множество клиентов и серверов на одном объекте моделирования. Такая модель значительно уменьшит как размер работ по конфигурации, которые необходимо выполнить, так и размер памяти, необходимой для выполнения моделирования.
Цель лабораторной работы заключается в оценке влияния различных конструкторских решений на работу и производительность сети.
3.2 Выполнение задания
Создание нового проекта
1. Запустить Riverbed Modeler Academic Edition и из меню File выбрать New.
49
2. Выбрать Project, нажать кнопку OK, назвать проект <инициалы>_NetDesign, сценарий SimpleNetwork
и нажать OK.
3. В окне Startup Wizard: Initial Topology выбрать Create Empty Scenario -> нажмите Next -> в списке Network Scale выбрать Campus -> нажать Next.
4. В окне Startup Wizard: Specify Size в выпадающем меню Units: выбрать Miles, присвоить 1 как X Span, так и Y Span, два раза нажать Next и нажать кнопку Finish.
Создание и настройка сети
Для инициализации сети нужно выполнить ниже перечисленные действия.
1. В верхней части проектного окна должно появиться диалоговое окно Object Palette. Если его там нет, то
необходимо открыть его, нажав 
. Следует убедиться, что из меню на этом окне выбран пункт internet_toolbox.
2. Добавить к проектному окну следующие объекты:
Application Config, Profile Config, subnet.
3. Чтобы добавить объект, нужно нажать на его изображение (знак), передвинуть мышь на рабочую область и щелкнуть левой кнопкой мыши, чтобы разместить объект. Затем нажать на правую кнопку мыши. Рабочее пространство должно содержать следующие три объекта (рисунок 3.1).
4. Закрыть диалоговое окно Object Palette и сохранить проект.
Рисунок 3.1 – Рабочее пространство
50