Описание локальной сети

В «МБОУ Шумковской ООШ» применена топология «звезда». Иерархическая «звезда» состоит из главного коммутатора, к которому подсоединены коммутаторы этажей. К ним подсоединяются рабочие станции.

Топология «звезда» имеет ряд преимуществ:

• — недорогой кабель и быстрая установка.
• — легкое объединение рабочих групп.
• — простое расширение сети.

Преимуществом такой топологии является также возможность простого исключения неисправного узла. Звездообразная топология обеспечивает защиту от разрыва кабеля. Если кабель рабочей станции будет поврежден, это не приведет к выходу из строя всего сегмента сети. Она позволяет также легко диагностировать проблемы подключения, так как каждая рабочая станция имеет свой собственный кабельный сегмент, подключенный к коммутатору. Для диагностики достаточно найти разрыв кабеля, который ведет к неработающей станции. Остальная часть сети продолжает нормально работать.

В школе архитектура клиент-серверная.

Архитектура клиент — сервер — это концепция информационной сети, в которой основная часть ее ресурсов сосредоточена в серверах, обслуживающих своих клиентов. Данная архитектура определяет два типа компонентов: серверы и клиенты.

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

Процесс, который вызывает сервисную функцию с помощью определенных операций, называется клиентом. Им может быть программа или пользователь.

Клиенты — это рабочие станции, которые используют ресурсы сервера и предоставляют удобные интерфейсы пользователя.

Сети клиент — серверной архитектуры имеют следующие преимущества:

• ? обеспечивают централизованное управление учетными записями пользователей, безопасностью и доступом, что упрощает сетевое администрирование;
• ? позволяют организовывать сети с большим количеством рабочих станций;
• ? обеспечивают эффективный доступ к сетевым ресурсам;
• ? предоставляют доступ ко всем сетевым ресурсам, на основе учетной записи пользователя.

Рисунок 2. Схема логической структуры сети

Характеристики сервера Системный блок:

Центральный процессор: Intel® Core™ i3−3240 (3M Cache, 3.40 GHz).

Материнская плата: ASRockH61M-VG4 Socket 1155 H61.

Оперативная память: Hynix DDR3 1600 DIMM 4Gb.

Видеокарта: ASUS GeForce GT 730 902Mhz PCI-E 2.0 1024Mb.

Блок питания: GIGABYTE GZ-EBS50N-C3, 500Вт Жесткий диск: Toshiba DT01ACA050 500Gb.

Привод: LG GH24NSD0.

Изображение Монитор: Viewsonic VA1903a.

Мультимедиа-проектор: Epson EB-S04.

Периферия Клавиатура: Logitech K120.

Мышь: DefenderMB-150.

Аудио система: Sven 249.

Оргтехника Принтер: CANONi-SENSYSMF212w.

Характеристика компьютеров первого этажа Системный блок:

Центральный процессор: AMDFX-6300 Vishera (AM3+, L3 8192Kb).

Материнская плата: ASUSM5A78L-MLX3.

Оперативная память: KingstonKVR13N9S8(2 ГБ) Видеокарта: Integrated Graphics Processor.

Блокпитания: HIPRO HPE-350W.

Жесткийдиск: Seagate ST320.

Привод: DVD-RW SAMSUNG SH-224 °F.

Изображение Монитор: ASUS VS197DE, 18.5.

Периферия Клавиатура: RAPOO N2210.

Мышь: LOGITECH M90.

Аудиосистема: LOGITECHS120.

Характеристика компьютеров второго этажа Системный блок:

Центральныйпроцессор: INTEL Celeron Dual-Core G1840, LGA 1150.

Материнская плата: MSI H81M-P33 LGA 1150, mATX.

Оперативная память: KINGSTON DDR3 — 2Гб 1600, DIMM x2.

Видеокарта: MSI GeForce 210, 1Гб, DDR3.

Блок питания: ACCORD ACC-350W-12, 350Вт Жесткий диск: WD Blue 320Гб, HDD, SATA III, 3.5.

Привод: DVD-RW SAMSUNG SH-224 °F.

Изображение Монитор: ASUS VS197DE, 18.5.

Периферия Клавиатура: RAPOO N2210.

Мышь: LOGITECHM90.

Коммутаторы:TP-LINKTL-SG1008PE-8-портовый гигабитный настольный/монтируемый в стойку коммутатор. Устройство предоставляет простую возможность расширения проводной сети посредством передачи данных и питания по единому кабелю Ethernet. TL-SG1008PEподдерживаетстандартPoweroverEthernetPlus (PoE+), который может автоматически обнаруживать и обеспечивать питанием устройства поддерживающие стандарт IEEE 802.3af/at.

Модем: TP-LINKTD-8840Tмаршрутизатор со встроенным модемом ADSL+ и с 4 портовым коммутатором представляет собой сетевое решение 2-в-1, которое сочетает в себе функции модема DSLи маршрутизатора с 4 портами Ethernet 10/100Мбит/с. Маркировка пакетов QoSна основе IPP/Tos, DSCPи 801.1p. Пропуск трафика VPN (PPTP, L2TP, IPSecPass-throungh).

Кроссплатформенные технологии:

Кроссплатформенные технологии обеспечивают совместную эксплуатацию различных аппаратных и программных платформ в интересах организаций-потребителей. программный приложение серверный сеть Основные архитектуры программного обеспечения Автономные (standalone) приложения Такими могут быть, как правило, сервисные программы, системные утилиты, текстовые и графические редакторы, компиляторы, достаточно простые корпоративные программы. Развитая корпоративная информационная система, как правило, не может состоять из отдельных, не связанных между собой компонентов.

Двухзвенная архитектура «клиент-сервер» .

Эта архитектура получила распространение с начала 1990;х годов на фоне роста рынка персональных компьютеров и снижения спроса на мэйнфреймы. В архитектуре «клиент-сервер» программное обеспечение разделено на две частиклиентскую часть и серверную часть. Задача клиентской-части (программы-клиента) состоит во взаимодействии с пользователем, передаче пользовательского запроса серверу, получение запроса от серверной части (программы-сервера) и представление его в удобном для пользователя виде. Программа-сервер же обрабатывает запросы клиента и выдает ответы. Классические примеры: Web-технологии (клиент-браузер, серверWeb-сервер), работа с распределенными СУБД (клиентспециальная программа, сервер — сервер базы данных). Развитие архитектуры «клиент-сервер», а особенно появление современных графических интерфейсов, привело сначала к появлению разновидности архитектуры клиент-сервер, называемой «архитектура с толстым клиентом» .Здесь логика представления данных и бизнес-логика размещаются на клиенте, который (скажем, в случае, когда сервером является СУБД) общается с логикой хранения и накопления данных на сервере, используя язык структурированных запросов SQL. Однако необходимость установки «толстых клиентов», требующих значительного количества специальных библиотек и специальной настройки окружения, на большое число пользовательских компьютеров с различными операционными средами, как правило вызывает массу проблем. Как альтернатива поэтому возникла также двухзвенная архитектура «с тонким клиентом» .При этом в идеале программа-клиент реализует лишь графический интерфейс пользователя (GUI) и передает/принимает запросы, а вся бизнес-логика выполняется сервером. В идеале клиентом является просто интернет-браузер, который имеется в стандартной операционной среде любого пользовательского компьютера и не требует специальной настройки, установки специализированного ПО и т. п. К сожалению, такая схема тоже не свободна от недостатков, хотя бы уже потому, что серверу приходится брать на себя иногда не свойственные для него функции реализации бизнес-логики приложения (например, серверу СУБД приходится выполнять расчеты!).

Многозвенная (multitiered) архитектура Начало процессу развития корпоративного программного обеспечения в многозвенной архитектуре было положено еще в рамках технологии «клиент/сервер». В них наряду с клиентской частью приложения и сервером баз данных появились серверы приложений (ApplicationServers).В идеале:

программа-клиент реализует GUI, передает запросы серверу приложений и принимает от него ответ, сервер приложений реализует бизнес-логику и обращается с запросами к серверу «третьего уровня» (например, серверу базы данных за данными),.

сервер третьего уровня обслуживает запросы сервера приложений.

Программа-клиент, таким образом, может быть «тонкой». Преимущества такой архитектуры очевидны:

изменения на каждом из звеньев можно осуществлять независимо;

снижаются нагрузки на сеть, поскольку звенья не обмениваются между собой большими объемами информации;

обеспечивается масштабирование и простая модернизация оборудования и программного обеспечения, поддерживающего каждое из звеньев, в том числе обновление серверного парка и терминального оборудования, СУБД и т. д.;

Приложения могут создаваться на стандартных языках третьего или четвертого поколения (Java, C/C++).

Следующий логический шаг — дальнейшее увеличение числа звеньев, причем возрастет не только за счет разбиения, когда «утоньшается» каждое из известных технических звеньев, но вся бизнес-модель строится как многозвенная. Современные корпоративные программные системы представляют собой, как правило, сложные системы взаимодействующих между собой на разных уровнях компонентов, каждые из которых могут являться клиентами для одних компонентов и серверами для других.

Основной проблемой систем, основанных на двухзвенной архитектуре «клиент-сервер», или тем более на многозвенной архитектуре, является то, что от них требуется мобильность в как можно более широком классе аппаратно-программных сред. Даже если ограничитьсяUNIXориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности. Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т. д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.

Общим решением проблемы мобильности такого рода систем является использование технологий, реализующие протоколы удаленного вызова процедур (RPC — Remote Procedure Call) стандартизованным и платформо независимым способом. При использовании таких технологий обращение к сервису в удаленном узле выглядит как обычный вызов процедуры (методов удаленных объектов). Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.

При вызове удаленной процедуры, программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы, и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся обратные преобразования. Таким образом, если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любуюоткрытую среду.

Технология CORBA.

CORBA (Common Object Request Broker Architecture) — это набор открытых спецификаций интерфейсов, определяющий архитектуру технологии межпроцессного и платформо независимого манипулирования объектами. Разработчиками данных интерфейсов являются OMG и X/Open.

Object Management Group, Inc. (OMG) — это интернациональная организация, основана в 1989 г., состоящая более чем из 800 членов: поставщиков информационных систем, разработчиков программного обеспечения и пользователей. OMG продвигает теорию и практику объектно-ориентированной технологии в область практической разработки программного обеспечения. Этот процесс включает в себя разработку промышленных стандартов и спецификаций управления объектами с целью создания общей базы для разработки программного обеспечения. Первоочередными задачами являются: повторное использование, переносимость и интероперабельность объектно-ориентированного программного обеспечения в распределенных, гетерогенных средах. Поддержка данных стандартов создает возможность разрабатывать гетерогенные приложения, работающие на всех основных платформах и операционных системах.

X/Open — независимая всемирная открытая организация, поддерживаемая большинством крупнейших поставщиков информационных систем, пользовательских организаций и компаний-производителей программного обеспечения. X/Open разрабатывает на основе существующих и создающихся стандартов всеобъемлющее и интегрированное системное окружение — Common Applications Environment (CAE).Компоненты CAE определены в стандартах X/OpenCAE. Основная цель CAE — создание пакетов программных интерфейсов (API) которые могут применяться на практике с сохранением максимальной переносимости на уровне исходных кодов программ. API также повышают уровень взаимодействия приложений при помощи предоставления определений и ссылок на протоколы и их профили.

Вышеназванные спецификации тщательно тестируются, выдержавшим тестирование присваивается X/Opentrademark (XPG brand), лицензированная X/Open.

Концептуальной инфраструктурой, на которой базируются все спецификации OMG, является Object Management Architecture (OMA).В состав OMA входят разнообразные стандартизованные или в настоящий момент стандартизируемые OMG службы, сервисы, программные образцы и шаблоны (CORBA services, horizontal and vertical CORBA facilities), язык определения интерфейсов распределенных объектов IDL (Interface Definition Language), стандартизованные или стандартизируемые отображения IDL на языки программирования и, наконец, объектная модельCORBA.

Реализовать технологию в соответствии со спецификациями может кто угодно. Созданные программные продукты, естественно, уже не являются открытыми, а становятся коммерческими продуктами.

Архитектура CORBA.

CORBA определяет, каким образом программные компоненты, распределенные по сети, могут взаимодействовать друг с другом вне зависимости от окружающих их операционных систем и языков реализации. Центральным элементом архитектуры CORBA является ORB (Object Request Broker) — программное обеспечение, обеспечивающее связь между объектами, в том числе позволяющее найти удаленный объект по Объектной Ссылке (IOR — InteroperableObjectReference),.

вызвать метод удаленного объекта, передав ему входные параметры (marshalingparameters),.

получить возвращаемое значение и выходящие параметры (unmarshalingparameters).

Тем самым ORB является связующим звеном между распределенными частями основанной на технологии CORBA системы, позволяя одной части системы не заботиться о физическом расположении других частей (объектов) системы. На рынке представлены ORB разных производителей (например, VisiBroker, WebLogic), но все они соответствуют единой спецификации CORBA. Поэтому в принципе CORBAпозволяет строить распределенные системы, одновременно используя ORB разных производителей, и строя систему одновременно на различных платформах и различных сетевых протоколах (это в терминологии CORBA называется интероперабельностьюinteroperability).В архитектуре CORBA каждый объект, методы которого доступны другим объектам (обычно его называют CORBAобъектом) имеет уникальную по всей доступной сети Объектную Ссылку (IOR — InteroperableObjectReference), по которой к нему можно обратиться. ИскатьCORBAобъекты можно как по IOR, так и по символическим именам, если они зарегистрированы (обычно при создании) в специальном сервисе имен (NameService).Для обращения к методам CORBAобъекта последний имеет открытый для всех остальных CORBAобъектов интерфейс. Интерфейсы CORBAобъектов принято описывать на специальном, определенном спецификацией CORBA языке IDL (InterfaceDefinitionLanguage). Производители ORB поставляют вместе с ORB также и утилиты, преобразующие описания интерфейсов CORBAобъектов в конструкции соответствующих языков программирования.

Основой интероперабельности является протокол GIOP — Generalinter-ORB Protocol, предназначенный для связи между объектами и ORB в сети. Стандартизация коммуникационного протокола позволяет разработчикам различных частей корпоративной системы совершенно не заботиться об используемых ORBах в других частях (ORB доменах) системы. Почти все современные ORBbi строятся на основе IIOP — Internetinter-ORB Protocol (это версия общего протоколаGIOP, предусматривающая использование в качестве транспортного протокола TCP/IP).

Спецификация CORBA предусматривает также ряд стандартизованных сервисов (CORBA Services) и горизонтальных и вертикальных Общих Средств (CommonFacilities). Сервисы представляют собой обычные CORBAобъекты со стандартизованными (и написанными на IDL) интерфейсами. К таким сервисам относится, например, уже упомянутый сервис имен NameService, сервис сообщений, позволяющий CORBAобъектам обмениваться сообщениями, сервис транзакций, позволяющий CORBAобъектам организовывать транзакции. В реальной системе не обязательно должны присутствовать все сервисы, их набор зависит от требуемой функциональности. На сегодня разработано всего 14 объектных сервисов.

Между объектными сервисами и общими средствами CORBA нет четкой границы. Последние тоже представляют собой CORBAобъекты со стандартизованными интерфейсами. CommonFacilities делятся на горизонтальные (общие для всех прикладных областей) и вертикальные (для конкретной прикладной области). Например, разработаны CommonFacilities для медицинских организаций, для ряда производств и т. п.