Системная сетевая архитектура

Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Найти источники:  «Системная сетевая архитектура»  -  новости  · газеты  · книги  · ученый  · JSTOR ( апрель 2019 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон )

Системная сетевая архитектура ( SNA ) - это проприетарная сетевая архитектура IBM , созданная в 1974 году. ^[1] Это полный стек протоколов для соединения компьютеров и их ресурсов. SNA описывает форматы и протоколы и сама по себе не является частью программного обеспечения. Внедрение SNA принимает форму различных коммуникационных пакетов, в первую очередь Virtual Telecommunication Access Method (VTAM), программного пакета для мэйнфреймов для коммуникаций SNA.

История [ править ]

SNA была обнародована как часть объявления IBM «Advanced Function for Communications» в сентябре 1974 г. ^[2], которое включало реализацию протоколов SNA / SDLC ( Synchronous Data Link Control ) в новых коммуникационных продуктах:

• Коммуникационный терминал IBM 3767 (принтер)
• Система передачи данных IBM 3770

Они поддерживались контроллерами связи IBM 3704/3705 и их программой управления сетью (NCP), а также System / 370 и их VTAM и другим программным обеспечением, таким как CICS и IMS. За этим объявлением последовало другое объявление в июле 1975 года, в котором была представлена станция ввода данных IBM 3760 , система связи IBM 3790 и новые модели системы отображения IBM 3270 .

SNA была в основном разработана лабораторией IBM Systems Development Division в Research Triangle Park , Северная Каролина , США, при поддержке других лабораторий, внедривших SNA / SDLC. Подробности позже были обнародованы в руководствах IBM System Reference Library и IBM Systems Journal .

СНС по-прежнему широко используется в банках и других сетях финансовых транзакций, а также во многих государственных учреждениях. Пока IBM еще ^{[ когда? ]} Оказывает поддержку СНС, одной из основных частей оборудования, в 3745 контроллер связи / 3746, был снят с рынка IBM. По оценкам, их насчитывается 20 000 ^{[ когда? ]} этих контроллеров установлены, и IBM продолжает предоставлять услуги по обслуживанию оборудования и микрокода для поддержки пользователей. Устойчивый рынок небольших компаний продолжает предоставлять 3745/3746, функции, запчасти и обслуживание. VTAM также поддерживается IBM, как и программа IBM Network Control Program (NCP), необходимая для контроллеров 3745/3746.

В 2008 году в публикации IBM говорилось:

С ростом популярности и роста TCP / IP SNA превращается из настоящей сетевой архитектуры в то, что можно было бы назвать «архитектурой доступа к приложениям и приложениям». Другими словами, есть много приложений, которым все еще необходимо обмениваться данными в SNA, но необходимые протоколы SNA передаются по сети по IP. ^[3]

Цели СНС [ править ]

В середине 1970-х годов IBM рассматривала себя в основном как поставщика оборудования, и, следовательно, все ее инновации в тот период были направлены на увеличение продаж оборудования. Целью SNA было снизить затраты на эксплуатацию большого количества терминалов и, таким образом, побудить клиентов разрабатывать или расширять интерактивные терминальные системы, а не пакетные системы. Расширение интерактивных систем на базе терминалов увеличит продажи терминалов и, что более важно, мэйнфреймов и периферийных устройств - отчасти из-за простого увеличения объема работы, выполняемой системами, а отчасти потому, что интерактивная обработка требует большей вычислительной мощности на транзакцию, чем на пакетную обработку. обработка.

Следовательно, SNA была направлена ​​на снижение основных затрат, не связанных с компьютером, и других трудностей при эксплуатации больших сетей с использованием более ранних протоколов связи. К трудностям относились:

• Часто линия связи не может использоваться терминалами разных типов, поскольку они используют разные «диалекты» существующих протоколов связи. До начала 1970-х компьютерные компоненты были настолько дорогими и громоздкими, что было невозможно включить универсальные коммуникационные интерфейсные карты в терминалы. Каждый тип терминала имел карту проводной связи, которая поддерживала работу только одного типа терминала без совместимости с другими типами терминалов на той же линии.
• Протоколы, с которыми могли работать примитивные коммуникационные карты, были неэффективными. Каждая линия связи использовала больше времени для передачи данных, чем современные линии.
• Линии связи в то время были гораздо более низкого качества. Например, было почти невозможно запустить линию коммутируемого доступа со скоростью более 19 200 бит в секунду из-за огромного количества ошибок, по сравнению с 56 000 бит в секунду сегодня на линиях коммутируемого доступа; и в начале 1970-х несколько выделенных линий работали со скоростью более 2400 бит в секунду (эти низкие скорости являются следствием закона Шеннона в относительно низкотехнологичной среде).

В результате для работы большого количества терминалов требовалось гораздо больше линий связи, чем требуется сегодня, особенно если требовалась поддержка разных типов терминалов или пользователи хотели использовать разные типы приложений (например, в рамках CICS или TSO ) из того же места. С чисто финансовой точки зрения цели SNA заключались в увеличении расходов клиентов на терминальные системы и в то же время в увеличении доли IBM в этих расходах, в основном за счет телекоммуникационных компаний.

SNA также была направлена ​​на преодоление ограничений архитектуры, которые мэйнфреймы IBM System / 370 унаследовали от System / 360 . Каждый ЦП мог подключаться не более чем к 16 каналам ввода-вывода ^[4], и каждый канал мог обрабатывать до 256 периферийных устройств, т.е. на один ЦП приходилось не более 4096 периферийных устройств. Во время разработки SNA каждая линия связи считалась периферийной. Таким образом, количество терминалов, с которыми могли бы взаимодействовать мощные мэйнфреймы, было ограничено.

Основные компоненты и технологии [ править ]

Усовершенствования в технологии компьютерных компонентов сделали возможным создание терминалов с более мощными коммуникационными картами, которые могли бы работать с одним стандартным протоколом связи, а не с очень упрощенным протоколом, который подходил только для определенного типа терминала. В результате, несколько протоколов связи многослойных были предложены в 1970 - х годах, из которых SNA компании IBM и ITU-T «s X.25 стали доминирующими позже.

Наиболее важные элементы СНС включают:

• IBM Network Control Program (NCP) - это программа связи, работающая на процессорах связи 3705 и последующих 37xx , которая, среди прочего, реализует протокол коммутации пакетов, определенный SNA. Протокол выполнял две основные функции:
  • Это протокол пересылки пакетов, действующий как современный коммутатор - пересылка пакетов данных на следующий узел, которым может быть мэйнфрейм, терминал или другой 3705. Коммуникационные процессоры поддерживали только иерархические сети с мэйнфреймом в центре, в отличие от современных маршрутизаторов, которые поддерживать одноранговые сети, в которых машина на конце линии может одновременно быть и клиентом, и сервером .
  • Это мультиплексор, который соединяет несколько терминалов в одну линию связи с ЦП, тем самым снимая ограничения на максимальное количество линий связи на ЦП. 3705 может поддерживать большее количество линий (изначально 352), но ЦП и каналы учитывают только одно периферийное устройство. С момента запуска SNA IBM представила улучшенные коммуникационные процессоры, последний из которых - 3745 .
• Synchronous Data Link Control ^[5] (SDLC), протокол, который значительно повысил эффективность передачи данных по одному каналу: ^[6]
  • Это протокол скользящего окна , который позволяет терминалам и коммуникационным процессорам 3705 отправлять кадры данных один за другим, не дожидаясь подтверждения предыдущего кадра - коммуникационные карты имели достаточно памяти и вычислительной мощности, чтобы запомнить последние 7 отправленных кадров или полученные, запрашивают повторную передачу только тех кадров, которые содержат ошибки, и помещают повторно переданные кадры в нужное место в последовательности перед их пересылкой на следующий этап.
  • Все эти фреймы имели один и тот же тип конверта (заголовок фрейма и трейлер) ^[7], который содержал достаточно информации для пакетов данных с разных типов терминалов, которые можно было отправлять по одной и той же линии связи, оставляя мэйнфрейм решать любые различия в форматировании содержимого или в правилах, регулирующих диалоги с разными типами терминалов.

Удаленные терминалы (например, подключенные к мэйнфрейму телефонными линиями) и процессоры связи 3705 будут иметь коммуникационные карты с поддержкой SDLC.

Это предшественник пакетной связи, которая в конечном итоге превратилась в сегодняшнюю технологию TCP / IP ^{[ необходима цитата ]} . Сама SDLC превратилась в HDLC , ^[8] одна из базовых технологий для выделенных каналов связи.

• VTAM , программный пакет для предоставления услуг входа в систему, ведения сеансов и маршрутизации в мэйнфрейме. Пользователь терминала должен войти через VTAM в конкретное приложение или среду приложений (например, CICS , IMS , DB2 или TSO / ISPF ). Затем устройство VTAM будет направлять данные от этого терминала в соответствующее приложение или среду приложений, пока пользователь не выйдет из системы и, возможно, не войдет в другое приложение. Исходные версии оборудования IBM могли поддерживать только один сеанс на каждый терминал. В 1980-х годах дополнительное программное обеспечение (в основном от сторонних поставщиков) позволяло терминалу иметь одновременные сеансы с различными приложениями или средами приложений.

Преимущества и недостатки [ править ]

Эта статья содержит список « за» и «против» , который иногда неуместен. Пожалуйста, помогите улучшить его , интегрировав обе стороны в более нейтральную презентацию, или удалите этот шаблон, если вы считаете, что такой список подходит для этой статьи. ( Ноябрь 2012 г. )

SNA удалила управление ссылками из прикладной программы и поместила его в NCP. Это имело следующие преимущества и недостатки:

Преимущества [ править ]

• Локализация проблем в телекоммуникационной сети была проще, потому что относительно небольшое количество программного обеспечения фактически имело дело с линиями связи. Была единая система сообщений об ошибках.
• Добавление коммуникационных возможностей к прикладной программе было намного проще, поскольку огромная область программного обеспечения для управления каналом связи, которое обычно требует процессоров прерываний и программных таймеров, была передана системному программному обеспечению и NCP .
• С появлением Advanced Peer-to-Peer Networking (APPN) за функциональность маршрутизации отвечал компьютер, а не маршрутизатор (как в сетях TCP / IP). Каждый компьютер поддерживал список узлов, определяющих механизмы пересылки. Централизованный тип узла, известный как сетевой узел, поддерживает глобальные таблицы всех других типов узлов. В APPN отпала необходимость в ведении таблиц маршрутизации расширенного межпрограммного взаимодействия (APPC), которые явно определяли связь между конечными точками. Сеансы APPN будут маршрутизироваться к конечным точкам через другие разрешенные типы узлов, пока не найдет место назначения. Это похоже на то, как маршрутизаторы для Интернет-протокола и межсетевого обмена пакетами Netwareфункция протокола. (APPN также иногда упоминается как PU2.1 или Physical Unit 2.1. APPC, также иногда упоминаемый как LU6.2 или Logical Unit 6.2, был единственным протоколом, определенным для сетей APPN, но изначально был одним из многих протоколов, поддерживаемых VTAM / NCP. вместе с LU0, LU1, LU2 (терминал 3270) и LU3. APPC в основном использовался между средами CICS, а также службами баз данных, поскольку он контактирует с протоколами для обработки двухфазной фиксации). Физические блоки: PU5 (VTAM), PU4 (37xx), PU2 (контроллер кластера). PU5 был самым способным и считался основным во всех коммуникациях. Другие устройства PU запросили соединение с PU5, и PU5 мог установить соединение или нет. Другие типы PU могут быть только вторичными по отношению к PU5. PU2.1 добавил возможность PU2.1 подключаться к другому PU2.1 в одноранговой среде.^[9] )

Недостатки [ править ]

• Подключение к сетям, не относящимся к SNA, было трудным. Приложение, которому требовался доступ к какой-либо схеме связи, которая не поддерживалась в текущей версии SNA, столкнулось с препятствиями. До того, как IBM включила поддержку X.25 (NPSI) в SNA, подключение к сети X.25 было бы затруднительным. Преобразование между протоколами X.25 и SNA могло быть обеспечено либо модификациями программного обеспечения NCP, либо внешним преобразователем протоколов .
• Связка альтернативных путей между каждой парой узлов в сети должна быть предварительно спроектирована и сохранена централизованно. Выбор между этими путями со стороны SNA был жестким и не позволял использовать преимущества текущих нагрузок на линии для обеспечения оптимальной скорости.
• Установка и обслуживание сети SNA сложны, а сетевые продукты SNA стоят (или были) дорогими. Попытки снизить сложность сети SNA за счет добавления функциональности IBM Advanced Peer-to-Peer Networking не увенчались успехом хотя бы потому, что переход от традиционной SNA к SNA / APPN был очень сложным и не приносил особой дополнительной ценности, по крайней мере, на начальном этапе. Лицензии на программное обеспечение SNA (VTAM) стоят до 10 000 долларов в месяц для высокопроизводительных систем. А контроллеры связи SNA IBM 3745 обычно стоят более 100 тысяч долларов. TCP / IP все еще считался непригодным для коммерческих приложений, например, в финансовой индустрии, до конца 1980-х годов, но быстро завоевал популярность в 1990-х годах из-за одноранговых сетей и технологии пакетной связи.
• SNA была создана в эпоху, когда концепция многоуровневой связи не была полностью принята компьютерной индустрией. Приложения, базы данных и коммуникационные функции были объединены в один и тот же протокол или продукт, что затрудняло обслуживание и управление. Это было очень распространено для продуктов, созданных в то время. Даже после того, как TCP / IP был полностью разработан, система X Window была разработана с использованием той же модели, в которой протоколы связи были встроены в приложение для графического отображения.
• Архитектура SNA, основанная на соединениях, использовала огромную логику конечного автомата для отслеживания всего. APPN добавила новое измерение в логику состояний с концепцией различных типов узлов. Хотя это было надежно, когда все работало правильно, все же требовалось ручное вмешательство. Такие простые вещи, как просмотр сеансов Control Point, приходилось делать вручную. APPN не обошлось без проблем; в первые дни многие магазины отказались от него из-за проблем, обнаруженных в поддержке APPN. Однако со временем многие проблемы были решены, но не раньше, чем TCP / IP стал все более популярным в начале 1990-х годов, что ознаменовало начало конца SNA.

Безопасность [ править ]

По своей сути, SNA была разработана с возможностью обертывать различные уровни соединений покровом безопасности. Чтобы общаться в среде SNA, вам сначала нужно подключиться к узлу, а также установить и поддерживать канальное соединение с сетью. Затем вам нужно согласовать правильный сеанс, а затем обработать потоки внутри самого сеанса. На каждом уровне существуют различные меры безопасности, которые могут управлять соединениями и защищать информацию о сеансе. ^[10]

Сетевые адресные устройства [ править ]

Сетевые адресные блоки в сети SNA - это любые компоненты, которым можно назначить адрес и которые могут отправлять и получать информацию. Далее они различаются следующим образом:

• System Services Контрольная точка (SSCP) обеспечивает управление ресурсами и другие сеансы службы (например, службы каталогов) для пользователей в сети подрайона; ^[11]
• Физический блок представляет собой комбинацию аппаратных и программных компонентов , которые контролируют ссылки на другие узлы. ^[12]
• логический блок выступает в качестве посредника между пользователем и сетью. ^[13]

Логическая единица (LU) [ править ]

По сути, SNA предлагает прозрачную связь: особенности оборудования, которые не накладывают никаких ограничений на связь LU-LU. Но в конечном итоге это служит цели различать типы LU, поскольку приложение должно учитывать функциональные возможности оконечного оборудования (например, размеры экрана и макет).

В SNA есть три типа потоков данных для подключения локальных терминалов и принтеров; есть символьная строка SNA (SCS), используемая для терминалов LU1 и для входа в сеть SNA с неформатированными системными службами (USS), есть поток данных 3270, который в основном используется мэйнфреймами, такими как System / 370 и последующими, включая Семейство zSeries и поток данных 5250 в основном используются миникомпьютерами / серверами, такими как System / 34 , System / 36 , System / 38 и AS / 400, а также его преемниками, включая System i и IBM Power Systems, на которых работает IBM i .

SNA определяет несколько видов устройств, называемых типами логических единиц: ^[14]

• LU0 предоставляет неопределенные устройства или создает свой собственный протокол. Это также используется для устройств, отличных от SNA 3270, поддерживаемых TCAM или VTAM.
• Устройства LU1 - это принтеры или комбинации клавиатур и принтеров.
• Устройства LU2 - это дисплейные терминалы IBM 3270.
• Устройства LU3 - это принтеры, использующие протоколы 3270.
• Устройства LU4 являются терминалами пакетной обработки.
• LU5 никогда не определялся.
• LU6 обеспечивает протоколы между двумя приложениями.
• LU7 обеспечивает сеансы с терминалами IBM 5250.

Основные используемые - это LU1, LU2 и LU6.2 (расширенный протокол для обмена данными между приложениями).

Физическая единица (PU) [ править ]

• Узлы PU1 - это терминальные контроллеры, такие как IBM 6670 или IBM 3767.
• Узлы PU2 - это кластерные контроллеры, на которых выполняются программы поддержки конфигурации, такие как IBM 3174 , IBM 3274 или IBM 4701 или IBM 4702 Branch Controller.
• Узлы PU2.1 являются одноранговыми (APPN) узлами
• PU3 никогда не определялся
• Узлы PU4 - это интерфейсные процессоры, на которых запущена программа управления сетью (NCP), например серия IBM 37xx
• Узлы PU5 являются главными компьютерными системами ^[15]

Термин 37xx относится к семейству контроллеров связи SNA от IBM . 3745 поддерживает до восьми высокоскоростных каналов T1 , 3725 - это крупномасштабный узел и интерфейсный процессор для хоста, а 3720 - удаленный узел, который функционирует как концентратор и маршрутизатор .

SNA через Token-Ring [ править ]

Узлы VTAM / NCP PU4, подключенные к сетям IBM Token Ring, могут совместно использовать одну и ту же инфраструктуру локальной сети с рабочими станциями и серверами. NCP инкапсулирует пакеты SNA в кадры Token-Ring, позволяя сеансам проходить по сети Token-Ring. Фактическая инкапсуляция и декапсуляция происходит в 3745.

SNA через IP [ править ]

Поскольку компании на базе мэйнфреймов искали альтернативы своим сетям на базе 37XX, IBM в середине 1990-х начала сотрудничать с Cisco и вместе они разработали коммутацию каналов передачи данных., или DLSw. DLSw инкапсулирует пакеты SNA в дейтаграммы IP, позволяя сеансам проходить по IP-сети. Фактическая инкапсуляция и декапсуляция происходит в маршрутизаторах Cisco на каждом конце однорангового соединения DLSw. На локальном сайте или сайте мэйнфрейма маршрутизатор использует топологию Token Ring для прямого подключения к VTAM. На удаленном (пользовательском) конце соединения эмулятор PU типа 2 (например, сервер шлюза SNA) подключается к одноранговому маршрутизатору через интерфейс LAN маршрутизатора. Терминалы конечных пользователей обычно представляют собой ПК с программным обеспечением эмуляции 3270, которое определено для шлюза SNA. Определение VTAM / NCP PU типа 2 становится коммутируемым главным узлом, который может быть локальным для VTAM (без NCP), а «линейное» соединение может быть определено с использованием различных возможных решений (таких как интерфейс Token Ring на 3745, 3172 Станция Канал Лань,или процессор интерфейса канала, совместимый с Cisco ESCON).

См. Также [ править ]

• Сетевой переносчик данных
• Протокол войны
• TN3270
• TN5250

Заметки [ править ]

Ссылки [ править ]

• Друг, Джордж Э .; Fike, John L .; Бейкер, Х. Чарльз; Беллами, Джон С. (1988). Понимание передачи данных (2-е изд.). Индианаполис: Ховард В. Самс и компания. ISBN 0-672-27270-9.
• Пуч, Удо В .; Грин, Уильям Х .; Мосс, Гэри Г. (1983). Телекоммуникации и сети . Бостон: Литтл, Браун и компания. ISBN 0-316-71498-4.
• Шатт, Стэн (1991). Связывание локальных сетей: руководство по микроменеджеру . Макгроу-Хилл. ISBN 0-8306-3755-9.
• Общая информация о системной сетевой архитектуре (PDF) . Первое издание. IBM. Январь 1975 г. GA27-3102-0.
• Концепции и продукты системной сетевой архитектуры (PDF) . Второе издание. IBM. Февраль 1984 г. GC30-3072-1.
• Системная сетевая архитектура Технический обзор . Пятое издание. IBM. Январь 1994. GC30-3073-04.
• Руководство по системной сетевой архитектуре для публикаций SNA . Третье издание. IBM. Июль 1994. GC30-3438-02.

Внешние ссылки [ править ]

• Статья Cisco о SNA
• Репозиторий документации по архитектуре мастерской разработчиков APPN
• Протоколы SNA довольно технические
• Связанные технические документы sdsusa.com
• Обзор расширенных функций для системы связи (PDF) . Второе издание. IBM. Июль 1975 г. GA27-3099-1 . Проверено 22 мая 2014 года . CS1 maint: discouraged parameter (link)
• Форматы системной сетевой архитектуры . Издание двадцать первое. IBM. Март 2004. GA27-3136-20.
• Системная сетевая архитектура - сеансы между логическими устройствами (PDF) . Третье издание. IBM. Апрель 1981 года. GC20-1868-2.
• Системная сетевая архитектура - Введение в сеансы между логическими устройствами (PDF) . Третье издание. IBM. Декабрь 1979 г. GC20-1869-2.
• Справочное руководство по формату и протоколу системной сетевой архитектуры: Архитектурная логика (PDF) . Третье издание. IBM. Ноябрь 1980 г. SY20-3112-2.
• Системная сетевая архитектура: Справочное руководство программиста транзакций для LU типа 6.2 . Издание шестое. IBM. Июнь 1993 г. GC30-3084-05.
• Системная сетевая архитектура Тип 2.1 Описание узлов . Пятое издание. IBM. Декабрь 1996 г. SC30-3422-04.
• Системная сетевая архитектура LU 6.2 Ссылка: протоколы равноправных узлов . Третье издание. IBM. Октябрь 1996 г. SC31-6808-02.