fix bibl, fix some chapters
This commit is contained in:
+59
-1
@@ -3,6 +3,64 @@
|
||||
|
||||
Под конфигурацией сети виртуальных машин в данной работе понимается формализованное описание набора виртуальных машин и связей между ними, необходимое для воспроизведения сетевой топологии лабораторного стенда. Такое описание должно фиксировать не только внешний вид схемы, но и параметры элементов сети, пригодные для дальнейшей обработки программой.
|
||||
|
||||
В состав описания конфигурации входят основные сущности сетевой топологии: узлы, сетевые интерфейсы и связи между ними. Узел соответствует виртуальной машине или иному элементу стенда. Для него могут задаваться имя, тип или роль в топологии, а также связанные с ним интерфейсы. Сетевой интерфейс описывает точку подключения узла к сети и может содержать имя интерфейса, MAC-адрес, IP-адрес и другие параметры, необходимые для настройки. Связь определяет соединение между интерфейсами или принадлежность интерфейса к определённому сетевому сегменту.
|
||||
В текущей версии модели описываются следующие элементы и поля:
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Топология сети}
|
||||
|
||||
Топология представляет собой полное описание рассматриваемой конфигурации. Она объединяет все устройства и сети, входящие в состав лабораторного стенда.
|
||||
|
||||
В составе топологии фиксируются:
|
||||
\begin{itemize}
|
||||
\item список устройств;
|
||||
\item список сетей;
|
||||
\end{itemize}
|
||||
|
||||
\item \textbf{Устройство}
|
||||
|
||||
Устройство соответствует отдельному элементу стенда. В зависимости от назначения оно может рассматриваться как хост, маршрутизатор или коммутатор. Такое деление нужно для указания роли устройства в топологии, но все эти элементы имеют общую структуру описания.
|
||||
|
||||
Для устройства задаются:
|
||||
\begin{itemize}
|
||||
\item \textbf{имя устройства}~--- уникальное обозначение элемента в пределах топологии;
|
||||
\item \textbf{роль устройства}~--- назначение элемента в сети, например хост, маршрутизатор или коммутатор;
|
||||
\item \textbf{набор сетевых интерфейсов}~--- перечень интерфейсов, принадлежащих данному устройству.
|
||||
\end{itemize}
|
||||
|
||||
Одно устройство может иметь один или несколько сетевых интерфейсов. Каждый интерфейс принадлежит ровно одному устройству.
|
||||
|
||||
\item \textbf{Сетевой интерфейс}
|
||||
|
||||
Сетевой интерфейс описывает точку подключения устройства к сети. Через интерфейсы задаются адресация, принадлежность к сетям, VLAN и отношения между физическими или логическими интерфейсами.
|
||||
|
||||
Для интерфейса задаются:
|
||||
\begin{itemize}
|
||||
\item \textbf{имя интерфейса}~--- обозначение интерфейса внутри устройства;
|
||||
\item \textbf{тип интерфейса}~--- характеристика интерфейса, например физический, виртуальный, VLAN-интерфейс или bridge-интерфейс;
|
||||
\item \textbf{адаптер}~--- сведения о сетевом адаптере, с которым связан интерфейс;
|
||||
\item \textbf{подчинённые интерфейсы}~--- список интерфейсов для bridge-интерфейса;
|
||||
\item \textbf{родительский интерфейс}~--- интерфейс, на основе которого создан vlan-интерфейс;
|
||||
\item \textbf{IP-адрес}~--- адрес интерфейса в соответствующей сети;
|
||||
\item \textbf{сеть}~--- имя сети или сегмента, к которому подключён интерфейс;
|
||||
\item \textbf{маска подсети}~--- параметр, определяющий размер IP-сети;
|
||||
\item \textbf{шлюз по умолчанию}~--- адрес маршрутизатора, используемый для выхода из сети;
|
||||
\item \textbf{VLAN}~--- идентификатор виртуальной локальной сети;
|
||||
\item \textbf{устройство-владелец}~--- устройство, которому принадлежит данный интерфейс.
|
||||
\end{itemize}
|
||||
|
||||
Интерфейс связан с одним устройством и может быть включён в одну сеть. При этом сеть может содержать несколько интерфейсов разных устройств.
|
||||
|
||||
\item \textbf{Сеть}
|
||||
|
||||
Сеть описывает общий сетевой сегмент, к которому могут быть подключены интерфейсы устройств. Она используется для группировки интерфейсов и задания их "физической" связи.
|
||||
|
||||
Для сети задаются:
|
||||
\begin{itemize}
|
||||
\item \textbf{имя сети}~--- обозначение сетевого сегмента в пределах топологии;
|
||||
\item \textbf{список подключённых интерфейсов}~--- интерфейсы устройств, входящие в данную сеть;
|
||||
\end{itemize}
|
||||
|
||||
Одна сеть может объединять один или несколько интерфейсов. Каждый интерфейс в текущей модели относится к одной сети или остаётся без указания сети, если этот параметр ещё не определён.
|
||||
\end{enumerate}
|
||||
|
||||
Так как на этапе планирования часть параметров может быть неизвестна, описание конфигурации должно допускать частично заполненные данные. Это позволяет зафиксировать структуру сети, а затем уточнять отдельные значения без изменения общей модели. Таким образом, конфигурация рассматривается как редактируемое структурированное описание, которое может быть представлено в табличном виде, использовано для построения диаграммы или экспортировано в формат YAML.
|
||||
|
||||
+107
-6
@@ -4,18 +4,119 @@
|
||||
|
||||
Поставленная задача состоит в разработке средства, позволяющего описывать частично сконфигурированную сеть виртуальных машин и получать на основе этого описания формализованное представление конфигурации. Для построения решения общая задача была разложена на несколько подзадач: определение состава описываемой информации, выбор формы представления данных, построение внутренней модели, разработка способа редактирования и реализация механизмов преобразования описания.
|
||||
|
||||
\todo[inline]{пока что нет конретики в том, какие поля мы описываем. Куда вставить их?}
|
||||
\subsection{Представление модели}
|
||||
|
||||
Первой подзадачей является определение состава информации, необходимой для описания сетевой конфигурации. Конфигурация сети виртуальных машин рассматривается как совокупность узлов, сетевых интерфейсов и связей между ними. Узел соответствует виртуальной машине, интерфейс задаёт точку подключения узла к сети, а связь описывает соединение интерфейсов или их принадлежность к одному сетевому сегменту. Для этих сущностей необходимо хранить имена, адреса, роли, параметры подключения и другие атрибуты, которые могут использоваться при последующей настройке или визуализации.
|
||||
Рассмотрение существующих решений показывает, что диаграмма удобна для визуального восприятия, но недостаточна как основная форма хранения данных: графическое изображение сложно интерпретировать как строгое описание конфигурации. Поэтому в качестве основы решения выбрано табличное представление данных, а диаграмма рассматривается только как производное отображение модели. Такой подход позволяет отделить логическое описание сети от способа его визуализации.
|
||||
|
||||
Второй подзадачей является выбор основного представления конфигурации. Рассмотрение существующих решений показывает, что диаграмма удобна для визуального восприятия, но недостаточна как основная форма хранения данных: графическое изображение сложно интерпретировать как строгое описание конфигурации. Поэтому в качестве основы решения выбрано табличное представление данных, а диаграмма рассматривается только как производное отображение модели. Такой подход позволяет отделить логическое описание сети от способа его визуализации.
|
||||
Табличная форма удобна тем, что позволяет явно фиксировать элементы сети и их атрибуты, редактировать отдельные значения и проверять заполненность полей. При этом она допускает частично заданные конфигурации: часть параметров может быть указана сразу, а часть оставлена пустой для последующего уточнения.
|
||||
|
||||
Третья подзадача связана с разработкой табличного способа задания конфигурации. Табличная форма удобна тем, что позволяет явно фиксировать элементы сети и их атрибуты, редактировать отдельные значения и проверять заполненность полей. При этом она допускает частично заданные конфигурации: часть параметров может быть указана сразу, а часть оставлена пустой для последующего уточнения.
|
||||
При разработке табличного представления конфигурации сети виртуальных машин рассматривались два варианта организации данных: представление в первой нормальной форме и представление в третьей нормальной форме. Оба варианта позволяют формализовать описание сети, однако различаются удобством редактирования данных.
|
||||
|
||||
Четвёртой подзадачей является построение внутренней модели данных. Табличное представление удобно для ввода, но для дальнейшей обработки требуется программная структура, в которой связи между объектами выражены явно. Поэтому данные таблиц должны преобразовываться во внутреннее представление, например в набор классов Python, соответствующих основным сущностям конфигурации. Такая модель служит центральным представлением, из которого могут формироваться другие виды результата.
|
||||
В первой нормальной форме данные представляются в виде одной или нескольких таблиц, где каждая строка содержит атомарные значения: имя узла, интерфейс, адреса, принадлежность сети и т.д.. Такое представление остаётся достаточно простым для ручного заполнения и позволяет сразу видеть основную структуру конфигурации.
|
||||
|
||||
Разберём оба представления на примере топологии, изображённой на рисунке~\ref{fig:exmpl1}
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{files/exmpl1.png}
|
||||
\caption{Пример топологии}
|
||||
\label{fig:exmpl1}
|
||||
\end{figure}
|
||||
|
||||
Пример представления в 1НФ:
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
\begin{tabular}{|l|l|l|l|l|}
|
||||
\hline
|
||||
\textbf{Name} & \textbf{Role} & \textbf{Interface} & \textbf{Network} & \textbf{Device IP} \\
|
||||
\hline
|
||||
PC1 & Host & eth1 & A & 10.0.0.1/24 \\
|
||||
PC2 & Host & eth1 & B & 10.0.0.2/24 \\
|
||||
PC3 & Host & eth1 & C & 10.0.0.3/24 \\
|
||||
PC4 & Host & eth1 & D & 10.0.0.4/24 \\
|
||||
com\_left & Switch & eth1 & tr & \\
|
||||
com\_left & Switch & eth2 & A & \\
|
||||
com\_left & Switch & eth3 & B & \\
|
||||
com\_right & Switch & eth1 & tr & \\
|
||||
com\_right & Switch & eth2 & D & \\
|
||||
com\_right & Switch & eth3 & C & \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Network device configuration}
|
||||
\end{table}
|
||||
|
||||
В третьей нормальной форме данные разделяются на отдельные сущности: узлы, интерфейсы, сетевые сегменты и связи. Такой подход уменьшает дублирование данных и лучше соответствует классической реляционной модели, однако делает представление более громоздким. Для понимания одной связи приходится обращаться сразу к нескольким таблицам.
|
||||
|
||||
Пример представления в 3НФ:
|
||||
|
||||
\begin{table}[h]
|
||||
\centering
|
||||
\begin{tabular}{|l|l|}
|
||||
\hline
|
||||
Name & Device \\
|
||||
\hline
|
||||
PC1 & Host \\
|
||||
PC2 & Host \\
|
||||
PC3 & Host \\
|
||||
PC4 & Host \\
|
||||
com\_left & Switch \\
|
||||
com\_right & Switch \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Devices}
|
||||
\end{table}
|
||||
|
||||
\begin{table}[h]
|
||||
\centering
|
||||
\begin{tabular}{|l|l|l|}
|
||||
\hline
|
||||
Host Name & Interface & Network \\
|
||||
\hline
|
||||
PC1 & eth1 & A \\
|
||||
PC2 & eth1 & B \\
|
||||
PC3 & eth1 & C \\
|
||||
PC4 & eth1 & D \\
|
||||
com\_left & eth1 & tr \\
|
||||
com\_left & eth2 & A \\
|
||||
com\_left & eth3 & B \\
|
||||
com\_right & eth1 & tr \\
|
||||
com\_right & eth2 & D \\
|
||||
com\_right & eth3 & C \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Interfaces}
|
||||
\end{table}
|
||||
|
||||
\begin{table}[h]
|
||||
\centering
|
||||
\begin{tabular}{|l|l|}
|
||||
\hline
|
||||
Interface & IP \\
|
||||
\hline
|
||||
PC1.eth1 & 10.0.0.1/24 \\
|
||||
PC2.eth1 & 10.0.0.2/24 \\
|
||||
PC3.eth1 & 10.0.0.3/24 \\
|
||||
PC4.eth1 & 10.0.0.4/24 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{IPs}
|
||||
\end{table}
|
||||
|
||||
В качестве основного пользовательского представления была выбрана первая нормальная форма. Она удобнее для ручного заполнения, проще воспринимается при описании лабораторных стендов и не требует постоянного перехода между большим количеством связанных таблиц.
|
||||
|
||||
Табличное представление в 1НФ используется как удобная форма ввода, а при дальнейшей обработке данные могут преобразовываться во внутреннюю модель, где отдельно выделяются узлы, интерфейсы и связи. Такой подход сохраняет простоту заполнения таблицы и одновременно позволяет использовать данные для экспорта в YAML или построения диаграммы топологии.
|
||||
|
||||
\subsection{Внутренняя модель данных}
|
||||
|
||||
Табличное представление удобно для ввода, но для дальнейшей обработки требуется программная структура, в которой связи между объектами выражены явно. Поэтому данные таблиц должны преобразовываться во внутреннее представление, например в набор классов Python, соответствующих основным сущностям конфигурации. Такая модель служит центральным представлением, из которого могут формироваться другие виды результата.
|
||||
|
||||
\todo[inline]{хоть и акцент обычно на табличках, это не совсем центральное. Представить пример uml для python классов}
|
||||
|
||||
Пятой подзадачей является разработка механизмов преобразования модели. Основными преобразованиями являются импорт данных из табличного описания во внутреннюю модель, экспорт в формализованный файл конфигурации и построение диаграммы топологии. YAML-файл в этом случае используется как структурированное описание, пригодное для дальнейшей обработки программами, вроде Netloom для поднятия сеьи из виртуальных машин, а D2 может применяться для генерации визуального представления сети на основе уже построенной модели.
|
||||
\subsection{Преобразование модели данных}
|
||||
|
||||
Также одной из подзадач является разработка механизмов преобразования модели. Основными преобразованиями являются импорт данных из табличного описания во внутреннюю модель, экспорт в формализованный файл конфигурации и построение диаграммы топологии. YAML-файл в этом случае используется как структурированное описание, пригодное для дальнейшей обработки программами, вроде Netloom для поднятия сеьи из виртуальных машин, а D2 может применяться для генерации визуального представления сети на основе уже построенной модели.
|
||||
|
||||
\subsection{Вывод}
|
||||
|
||||
Таким образом, решение строится не вокруг построения диаграммы, а вокруг формальной модели сетевой конфигурации. Табличное представление используется как способ ввода и редактирования, внутренняя модель — как основа обработки данных, а YAML и диаграмма — как формы представления результата. Такой подход позволяет обеспечить редактируемость, воспроизводимость и возможность дальнейшего применения описания при подготовке лабораторных стендов из виртуальных машин.
|
||||
+8
-1
@@ -1,3 +1,10 @@
|
||||
\section{Описание практической части}
|
||||
\label{sec:Chapter4} \index{Chapter4}
|
||||
\todo[inline]{Если в рамках работы писался какой-то код, здесь должно быть его описание: выбранный язык и библиотеки и мотивы выбора, архитектура, схема функционирования, теоретическая сложность алгоритма, характеристики функционирования (скорость/память).}
|
||||
\todo[inline]{Если в рамках работы писался какой-то код, здесь должно быть его описание: выбранный язык и библиотеки и мотивы выбора, архитектура, схема функционирования, теоретическая сложность алгоритма, характеристики функционирования (скорость/память).}
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{files/UML.png}
|
||||
\caption{UML диаграмма классов Python}
|
||||
\label{fig:uml_model}
|
||||
\end{figure}
|
||||
+22
-20
@@ -1,16 +1,20 @@
|
||||
\begin{thebibliography}{}
|
||||
|
||||
\bibitem{drawio}
|
||||
draw.io. Configurable diagramming application, 2026. Available at \url{https://github.com/jgraph/drawio/wiki} (accessed May~19, 2026).
|
||||
|
||||
\bibitem{TEST}
|
||||
\textbf{Балашов\;В.\;В., Абрамов \;А.\;В., Чупахин \;А.\;А. и др.} Муравьиный алгоритм
|
||||
для построения однопроцессорного расписания с минимизацией пикового
|
||||
использования ресурса~// Дискретный анализ и исследование операций. –
|
||||
2024. – Т. 31, №2. – С. 5–26.
|
||||
\bibitem{Lucidchart}
|
||||
Lucidchart. Visual workspace for diagramming, 2026. Available at \url{https://www.lucidchart.com/pages} (accessed May~19, 2026).
|
||||
|
||||
\bibitem{DB}
|
||||
\textbf{Date \;C.\;J.} Введение в системы баз данных~// Издательский дом "Вильяме". – 2005. – 457-488 с.
|
||||
|
||||
\bibitem{BAKER}
|
||||
\textbf{Baker \;K.\;R., Trietsch \;D.} Principles of Sequencing and Scheduling~// John Wiley \& Sons. – 2009. – 510 p.
|
||||
\bibitem{Visio}
|
||||
Microsoft Visio. Visual workspace for diagramming, 2026. Available at \url{https://support.microsoft.com/en-US/Visio/beginner-tutorial-for-visio} (accessed May~19, 2026).
|
||||
|
||||
\bibitem{Cisco}
|
||||
Cisco Packet Tracer. Network simulation tool, 2026. Available at \url{https://www.netacad.com/cisco-packet-tracer} (accessed May~19, 2026).
|
||||
|
||||
\bibitem{eNSP}
|
||||
Huawei eNSP. Enterprise network simulation platform, 2026. Available at \url{https://support.huawei.com/enterprise/en/nce-data-communication/ensp-pid-9017384} (accessed May~19, 2026).
|
||||
|
||||
\bibitem{D2}
|
||||
D2. Diagram scripting language, 2026. Available at \url{https://d2lang.com/tour/intro/} (accessed May~19, 2026).
|
||||
@@ -21,20 +25,18 @@ Graphviz. Open source graph visualization software, 2026. Available at \url{http
|
||||
\bibitem{PlantUML}
|
||||
PlantUML. Tool for creation of a wide array of diagrams, 2026. Available at \url{https://plantuml.com/guide} (accessed May~19, 2026).
|
||||
|
||||
\bibitem{Cisco}
|
||||
Cisco Packet Tracer. Network simulation tool, 2026. Available at \url{https://www.netacad.com/cisco-packet-tracer} (accessed May~19, 2026).
|
||||
\bibitem{DB}
|
||||
\textbf{Date \;C.\;J.} Введение в системы баз данных~// Издательский дом "Вильяме". – 2005. – 457-488 с.
|
||||
|
||||
\bibitem{eNSP}
|
||||
Huawei eNSP. Enterprise network simulation platform, 2026. Available at \url{https://support.huawei.com/enterprise/en/nce-data-communication/ensp-pid-9017384} (accessed May~19, 2026).
|
||||
\bibitem{TEST}
|
||||
\textbf{Балашов\;В.\;В., Абрамов \;А.\;В., Чупахин \;А.\;А. и др.} Муравьиный алгоритм
|
||||
для построения однопроцессорного расписания с минимизацией пикового
|
||||
использования ресурса~// Дискретный анализ и исследование операций. –
|
||||
2024. – Т. 31, №2. – С. 5–26.
|
||||
|
||||
\bibitem{Lucidchart}
|
||||
Lucidchart. Visual workspace for diagramming, 2026. Available at \url{https://www.lucidchart.com/pages} (accessed May~19, 2026).
|
||||
|
||||
\bibitem{Visio}
|
||||
Microsoft Visio. Visual workspace for diagramming, 2026. Available at \url{https://support.microsoft.com/en-US/Visio/beginner-tutorial-for-visio} (accessed May~19, 2026).
|
||||
|
||||
\bibitem{drawio}
|
||||
draw.io. Configurable diagramming application, 2026. Available at \url{https://github.com/jgraph/drawio/wiki} (accessed May~19, 2026).
|
||||
|
||||
\bibitem{BAKER}
|
||||
\textbf{Baker \;K.\;R., Trietsch \;D.} Principles of Sequencing and Scheduling~// John Wiley \& Sons. – 2009. – 510 p.
|
||||
|
||||
\end{thebibliography}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 210 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 286 KiB |
@@ -0,0 +1,49 @@
|
||||
дд: в пт 10:00
|
||||
|
||||
/раздел 4.1 перетянуть в 2 раздел
|
||||
|
||||
?4.1 4.2 - представление конфигурации сети для редактирования
|
||||
ссылка на 2 раздел, отсылка к обзору
|
||||
/=> 4.2 и 4.3 объединяются
|
||||
|
||||
/убрать подсчёт подзадач
|
||||
|
||||
набор полей в таблице
|
||||
|
||||
почему остальные нф нет
|
||||
|
||||
сслыки на таблицы тоже
|
||||
явное определение 3нф и 1нф
|
||||
ввести сокращение
|
||||
убрать рамку
|
||||
|
||||
/сделать более полную таблицу
|
||||
|
||||
- no need
|
||||
|
||||
UML перенести в 4.4
|
||||
вырезать все методы у UML
|
||||
|
||||
раздел 4.5 в описание программной реализации
|
||||
там же говорим и про csv - модель данных - yaml
|
||||
|
||||
- диаграмма как что куда генерится (пунктиром развертывание конфигурации сети)
|
||||
|
||||
Переименвать 4 в Построение модели данных
|
||||
|
||||
В 5 раздел
|
||||
Объектная там, делает преобразования такие-то
|
||||
объем строк, размер, бла-бла, гитхаб репу
|
||||
там же картинки с визуализацией
|
||||
тут же в подразделе, что только L1
|
||||
табличное - внешний редактор (в диаграмках)
|
||||
|
||||
заключение
|
||||
в будущем:
|
||||
разработка редактора конфигурации сети, использующее модель
|
||||
доп отображение уровней
|
||||
по итогу:
|
||||
разработана модель
|
||||
выполнено сопряженение
|
||||
на основе обзора табличное редактирование сторонним редактором
|
||||
разработана программа для преобразования табл в входной язык netloom. Програмное средство трансляцию и визуализацию
|
||||
Reference in New Issue
Block a user