Системная сетевая архитектура IBM (SNA)

Введение

Проприетарная сетевая архитектура, разработанная IBM.

Системная сетевая архитектура (SNA) — это запатентованная сетевая архитектура IBM, созданная в 1974 году. Она представляет собой полный стек протоколов для соединения компьютеров и их ресурсов. SNA определяет форматы и протоколы, но сама по себе не является программным обеспечением. Реализация SNA осуществляется в виде различных коммуникационных пакетов, наиболее известным из которых является метод виртуального доступа к телекоммуникациям (VTAM) — программный пакет для мейнфреймов, обеспечивающий коммуникации по SNA.

Цели СНС

IBM в середине 1970-х годов рассматривала себя преимущественно как поставщика аппаратного обеспечения, и поэтому все ее инновации в тот период были направлены на увеличение продаж оборудования. Целью SNA было снижение затрат на эксплуатацию большого числа терминалов и, как следствие, стимулирование клиентов к разработке или расширению интерактивных терминальных систем вместо пакетных. Расширение интерактивных терминальных систем должно было увеличить продажи терминалов и, что более важно, мейнфреймов и периферийных устройств – отчасти за счет простого увеличения объема выполняемой работы, а отчасти потому, что интерактивная обработка требует большей вычислительной мощности на транзакцию, чем пакетная. Таким образом, SNA стремилась сократить основные некомпьютерные затраты и другие трудности при эксплуатации крупных сетей, использующих более ранние протоколы связи. Эти трудности включали: часто линией связи не могли пользоваться терминалы разных типов, поскольку они использовали различные "диалекты" существующих протоколов связи. До начала 1970-х годов компьютерные компоненты были настолько дорогими и громоздкими, что включение универсальных карт интерфейса связи в терминалы было нецелесообразным. Каждый тип терминала имел аппаратную карту связи, поддерживающую работу только одного типа терминала и несовместимую с другими типами терминалов на той же линии. Протоколы, которые могли обрабатывать эти примитивные карты связи, были неэффективны. Каждая линия связи тратила больше времени на передачу данных, чем современные. Телекоммуникационные линии того времени были значительно хуже по качеству. Например, из-за чрезмерно высокой частоты ошибок было практически невозможно организовать подключение по коммутируемой линии со скоростью более 19 200 бит в секунду, в то время как сегодня по таким линиям достигается скорость 56 000 бит в секунду; и в начале 1970-х годов лишь немногие арендованные линии работали со скоростью выше 2400 бит в секунду (эти низкие скорости обусловлены законом Шеннона в условиях относительно неразвитой технологической базы). В результате, для работы с большим числом терминалов требовалось значительно больше линий связи, чем сегодня, особенно если необходимо было поддерживать различные типы терминалов или пользователи хотели использовать различные типы приложений (например, под CICS или TSO) из одного и того же места. С чисто финансовой точки зрения, цели SNA заключались в увеличении расходов клиентов на терминальные системы и одновременном увеличении доли IBM в этих расходах, главным образом за счет телекоммуникационных компаний. SNA также была направлена на преодоление ограничения архитектуры, унаследованного мейнфреймами IBM System/370 от System/360. Каждый процессор мог подключаться максимум к 16 каналам ввода-вывода, и каждый канал мог обслуживать до 256 периферийных устройств, то есть максимум 4096 периферийных устройств на процессор. В момент разработки SNA каждая линия связи считалась периферийным устройством. Таким образом, число терминалов, с которыми могли взаимодействовать мощные мейнфреймы, было ограничено.

IBM in the mid 1970s saw itself mainly as a hardware vendor and hence all its innovations in that period aimed to increase hardware sales. SNA's objective was to reduce the costs of operating large numbers of terminals and thus induce customers to develop or expand interactive terminal based systems as opposed to batch systems. An expansion of interactive terminal based systems would increase sales of terminals and more importantly of mainframe computers and peripherals partly because of the simple increase in the volume of work done by the systems and partly because interactive processing requires more computing power per transaction than batch processing. Hence SNA aimed to reduce the main non computer costs and other difficulties in operating large networks using earlier communications protocols. The difficulties included:
Often a communications line could not be shared by terminals of different types, as they used different "dialects" of the existing communications protocols. Up to the early 1970s, computer components were so expensive and bulky that it was not feasible to include all purpose communications interface cards in terminals. Every type of terminal had a hard wired communications card which supported only the operation of one type of terminal without compatibility with other types of terminals on the same line. The protocols which the primitive communications cards could handle were not efficient. Each communications line used more time transmitting data than modern lines do. Telecommunications lines at the time were of much lower quality. For example, it was almost impossible to run a dial up line at more than 19,200 bits per second because of the overwhelming error rate, as compared with 56,000 bits per second today on dial up lines; and in the early 1970s few leased lines were run at more than 2400 bits per second (these low speeds are a consequence of Shannon's Law in a relatively low technology environment). As a result, running a large number of terminals required a lot more communications lines than the number required today, especially if different types of terminals needed to be supported, or the users wanted to use different types of applications (. e. g. under CICS or TSO) from the same location. In purely financial terms SNA's objectives were to increase customers' spending on terminal based systems and at the same time to increase IBM's share of that spending, mainly at the expense of the telecommunications companies. SNA also aimed to overcome a limitation of the architecture which IBM's System/370 mainframes inherited from System/360. Each CPU could connect to at most 16 I/O channels and each channel could handle up to 256 peripherals i. e. there was a maximum of 4096 peripherals per CPU. At the time when SNA was designed, each communications line counted as a peripheral. Thus the number of terminals with which powerful mainframes could otherwise communicate was limited.

Преимущества и недостатки

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

Преимущества

Локализация проблем в телекоммуникационной сети была проще, поскольку относительно небольшое количество программного обеспечения фактически обрабатывало каналы связи. Существовала единая система отчетов об ошибках. Добавление функциональности связи в прикладную программу было намного легче, поскольку сложная область программного обеспечения управления каналами, которая обычно требует прерывающих процессоров и программных таймеров, была делегирована системному программному обеспечению и NCP. С появлением Advanced Peer to Peer Networking (APPN) функция маршрутизации стала ответственностью компьютера, а не маршрутизатора (как в сетях TCP/IP). Каждый компьютер поддерживал список узлов, определяющих механизмы пересылки. Централизованный тип узла, известный как сетевой узел, вел глобальные таблицы всех остальных типов узлов. APPN отменила необходимость поддерживать таблицы маршрутизации Advanced Program to Program Communication (APPC), которые явно определяли соединение между конечными точками. Сеансы APPN направлялись к конечным точкам через другие разрешенные типы узлов, пока не находили пункт назначения. Это аналогично работе маршрутизаторов для протокола Internet Protocol и протокола Netware Internetwork Packet Exchange. (APPN также иногда называют PU2.1 или физической единицей 2.1. APPC, также иногда называемый LU6.2 или логическим блоком 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 в одноранговой среде.

Localization of problems in the telecommunications network was easier because a relatively small amount of software actually dealt with communication links. There was a single error reporting system. Adding communication capability to an application program was much easier because the formidable area of link control software that typically requires interrupt processors and software timers was relegated to system software and NCP. With the advent of Advanced Peer to Peer Networking (APPN), routing functionality was the responsibility of the computer as opposed to the router (as with TCP/IP networks). Each computer maintained a list of Nodes that defined the forwarding mechanisms. A centralized node type known as a Network Node maintained Global tables of all other node types. APPN stopped the need to maintain Advanced Program to Program Communication (APPC) routing tables that explicitly defined endpoint to endpoint connectivity. APPN sessions would route to endpoints through other allowed node types until it found the destination. This is similar to the way that routers for the Internet Protocol and the Netware Internetwork Packet Exchange protocol function. (APPN is also sometimes referred to PU2.1 or Physical Unit 2.1. APPC, also sometime referred to LU6.2 or Logical Unit 6.2, was the only protocol defined to APPN networks, but was originally one of many protocols supported by VTAM/NCP, along with LU0, LU1, LU2 (3270 Terminal), and LU3. APPC was primarily used between CICS environments, as well as database services, because it contact protocols for 2 phase commit processing). Physical Units were PU5 (VTAM), PU4 (37xx), PU2 (Cluster Controller). A PU5 was the most capable and considered the primary on all communication. Other PU devices requested a connection from the PU5 and the PU5 could establish the connection or not. The other PU types could only be secondary to the PU5. A PU2.1 added the ability to a PU2.1 to connect to another PU2.1 in a peer to peer environment.)

Недостатки

Подключение к сетям, отличным от 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 долларов в месяц для высокопроизводительных систем. А коммуникационные контроллеры IBM 3745 для SNA обычно стоили более 100 000 долларов. TCP/IP до конца 1980-х годов считался непригодным для коммерческих приложений, например, в финансовой сфере, но быстро завоевал популярность в 1990-х годах благодаря своей одноранговой сети и технологии пакетной передачи данных. Архитектура SNA, основанная на установлении соединений, использовала сложную логику конечных автоматов для отслеживания всех операций. APPN добавил новое измерение в логику состояний благодаря концепции различных типов узлов. Несмотря на надежность при корректной работе, все еще требовалось ручное вмешательство. Даже такие простые задачи, как мониторинг сеансов контрольной точки, приходилось выполнять вручную. APPN не был лишен недостатков; на ранних этапах многие организации отказались от него из-за проблем, обнаруженных в поддержке APPN. Однако со временем многие из этих проблем были решены, но к тому времени TCP/IP уже приобрел все большую популярность в начале 1990-х годов, что ознаменовало начало конца для SNA.

Connection to non SNA networks was difficult. An application that needed access to some communication scheme not supported in the current version of SNA would have faced obstacles. Before IBM included X.25 support (NPSI) in SNA, connecting to an X.25 network would have been awkward. Conversion between X.25 and SNA protocols could have been provided either by NCP software modifications or by an external protocol converter. A sheaf of alternate pathways between every pair of nodes in a network had to be predesigned and stored centrally. Choice among these pathways by SNA was rigid and did not take advantage of current link loads for optimum speed. SNA network installation and maintenance are complicated and SNA network products are (or were) expensive. Attempts to reduce SNA network complexity by adding IBM Advanced Peer to Peer Networking functionality were not really successful, if only because the migration from traditional SNA to SNA/APPN was very complex, without providing much additional value, at least initially. SNA software licences (VTAM) cost as much as $10,000 a month for high end systems. And SNA IBM 3745 Communications Controllers typically cost over $100K. TCP/IP was still seen as unfit for commercial applications e. g. in the finance industry until the late 1980s, but rapidly took over in the 1990s due to its peer to peer networking and packet communication technology. SNA's connection based architecture invoked huge state machine logic to keep track of everything. APPN added a new dimension to state logic with its concept of differing node types. While it was solid when everything was running correctly, there was still a need for manual intervention. Simple things like watching the Control Point sessions had to be done manually. APPN wasn't without issues; in the early days many shops abandoned it due to issues found in APPN support. Over time, however, many of the issues were worked out but not before TCP/IP became increasingly popular in the early 1990s, which marked the beginning of the end for SNA.

Безопасность

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

SNA через Token-Ring

ВТАМ/NCP PU4 узлы, подключенные к сетям IBM Token Ring, могут совместно использовать инфраструктуру локальной сети с рабочими станциями и серверами. NCP инкапсулирует пакеты SNA в кадры Token Ring, обеспечивая передачу сеансов по сети Token Ring. Непосредственная инкапсуляция и декапсуляция выполняются в устройстве 3745.

SNA через IP

Поскольку организации, использующие мэйнфреймы, искали альтернативы своим сетям на базе 37XX, IBM в середине 1990-х годов объединила усилия с Cisco, и вместе они разработали технологию Data Link Switching, или 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, станция Lan Channel 3172 или совместимый с Cisco ESCON процессор интерфейса каналов.

Конкуренты

Проприетарная сетевая архитектура для мейнфреймов Honeywell Bull – это архитектура распределенных систем (DSA). Пакет связи для DSA – VIP. DSA также больше не поддерживается для клиентского доступа. Мейнфреймы Bull оснащены Mainway для преобразования DSA в TCP/IP, а устройства VIP заменены эмуляциями терминалов TNVIP (GLink, Winsurf). GCOS 8 поддерживает TNVIP SE через TCP/IP. Сетевой архитектурой для мейнфреймов Univac была архитектура распределенных вычислений (DCA), а сетевой архитектурой для мейнфреймов Burroughs – сетевая архитектура Burroughs (BNA); после их слияния в Unisys обе архитектуры предоставлялись объединенной компанией. Обе они устарели к 2012 году. International Computers Limited (ICL) разработала свою архитектуру обработки информации (IPA). DECnet – это набор сетевых протоколов, созданный Digital Equipment Corporation, впервые выпущенный в 1975 году для соединения двух миникомпьютеров PDP 11. Он эволюционировал в одну из первых пиринговых сетевых архитектур, что превратило DEC в лидера в области сетевых технологий в 1980-х годах. SNA также конкурировала с Open Systems Interconnection от ISO, представлявшей собой попытку создать независимую от поставщика сетевую архитектуру, которая не удалась из-за проблем, связанных с "разработкой коллективным разумом". Системы OSI очень сложны, и многочисленные участники требовали значительной гибкости, что негативно сказывалось на совместимости систем OSI, которая изначально была главной целью. В течение многих лет пакет TCP/IP не рассматривался IBM как серьезная альтернатива, отчасти из-за отсутствия контроля над интеллектуальной собственностью. Публикация 1988 года, автором которой является Яков Рехтер, определяющая возможность запуска сессий IBM 3270 через Telnet, явно признает потребность клиентов в совместимости в ЦОД. Впоследствии IETF расширил эту работу, разработав множество других RFC. TN3270 (Telnet 3270), определенный в этих RFC, поддерживает прямое клиент-серверное соединение с мейнфреймом с использованием сервера TN3270 на мейнфрейме и пакета эмуляции TN3270 на компьютере конечного пользователя. Этот протокол позволяет существующим приложениям VTAM (CICS, TSO) работать с минимальными или отсутствующими изменениями по сравнению с традиционной SNA, поддерживая традиционный терминальный протокол 3270 поверх сеанса TCP/IP. Этот протокол широко используется для замены устаревшего SNA-соединения, в большей степени, чем Data Link Switching (DLSw) и другие технологии замены SNA. Существует аналогичный вариант TN5250 (Telnet 5250) для IBM 5250.

The proprietary networking architecture for Honeywell Bull mainframes is Distributed Systems Architecture (DSA). The Communications package for DSA is VIP. DSA is also no longer supported for client access. Bull mainframes are fitted with Mainway for translating DSA to TCP/IP and VIP devices are replaced by TNVIP Terminal Emulations (GLink, Winsurf). GCOS 8 supports TNVIP SE over TCP/IP. The networking architecture for Univac mainframes was the Distributed Computing Architecture (DCA), and the networking architecture for Burroughs mainframes was the Burroughs Network Architecture (BNA); after they merged to form Unisys, both were provided by the merged company. Both were largely obsolete by 2012. International Computers Limited (ICL) provided its Information Processing Architecture (IPA). DECnet is a suite of network protocols created by Digital Equipment Corporation, originally released in 1975 to connect two PDP 11 minicomputers. It evolved into one of the first peer to peer network architectures, thus transforming DEC into a networking powerhouse in the 1980s. SNA also competed with ISO's Open Systems Interconnection, which was an attempt to create a vendor neutral network architecture that failed due to the problems of "design by committee". OSI systems are very complex, and the many parties involved required extensive flexibilities that hurt the interoperability of OSI systems, which was the prime objective to start with. The TCP/IP suite for many years was not considered a serious alternative by IBM, due in part to the lack of control over the intellectual property. The 1988 publication of , authored by Yakov Rekhter, which defines an option to run IBM 3270 sessions over Telnet, explicitly recognizes the customer demand for interoperability in the data center. Subsequently, the IETF expanded on this work with multiple other RFCs. TN3270 (Telnet 3270), defined by those RFCs, supports direct client server connections to the mainframe using a TN3270 server on the mainframe, and a TN3270 emulation package on the computer at the end user site. This protocol allows existing VTAM applications (CICS, TSO) to run with little or no change from traditional SNA by supporting traditional 3270 terminal protocol over the TCP/IP session. This protocol is widely used to replace legacy SNA connectivity more than Data Link Switching (DLSw) and other SNA replacement technologies. A similar TN5250 (Telnet 5250) variant exists for the IBM 5250.

Не IBM SNA реализация

Программное обеспечение SNA, не разработанное IBM, позволяло системам, отличным от систем IBM, взаимодействовать с мейнфреймами IBM и компьютерами среднего класса AS/400, используя протоколы SNA. Некоторые производители Unix-систем, такие как Sun Microsystems с линейкой продуктов SunLink SNA, включая PU2.1 Server, и Hewlett Packard/Hewlett Packard Enterprise с продуктом SNAplus2, предлагали программное обеспечение SNA. Microsoft представила SNA Server для Windows в 1993 году; теперь он известен как Microsoft Host Integration Server. Digital Equipment Corporation предлагала VMS/SNA для VMS. Существовали сторонние программные пакеты SNA для VMS, такие как продукты VAX Link от Systems Strategies, Inc.

Brixton Systems разработала несколько программных пакетов SNA, продаваемых под брендом "Brixton", например Brixton BrxPU21, BrxPU5, BrxLU62 и BrxAPPC, для систем, таких как рабочие станции Hewlett Packard и Sun Microsystems. IBM поддерживала использование нескольких не-IBM программных реализаций APPC/PU2.1/LU6.2 для связи с z/OS, включая SNAplus2 для систем HP, Brixton 4.1 SNA для Sun Solaris и SunLink SNA 9.1 Support для Sun Solaris.