IBM e Server Linux on z Series Module
IBM e. Server™ Linux on z. Series Module 12: Networking 2004 IBM Corporation
IBM e. Server™ Sections: § Basic Networking Concepts § Linux Networking § Networking Connectivity Options § Networking in a z/VM< Environment § References 2 © 2004 IBM Corporation
IBM e. Server™ Objectives § § § List the two differences between Static and Dynamic IP addresses List the three methods of setting up resilient IP addressing List two types of DNS Define VIPA and state how it works Compare virtual networking to physical networking from both a network and processing perspective List three options for choosing a routing protocol List 5 types of configuration files that are needed for your networking environment Briefly describe the use of the Inetd daemon List the five methods a user can utilize to access data and applications State the features of OSA State the function of the OAT Define VCTC and state its advantage over CTC 3 © 2004 IBM Corporation
IBM e. Server™ Objectives § State the use of IUCV § Briefly describe Hiper. Sockets § State two advantages of using Hiper. Sockets in a Linux on z. Series environment compared to a physical connection 4 © 2004 IBM Corporation
IBM e. Server™ Basic Networking Concepts § § § TPL (Transport Layer Protocols) IPv 6 tools IP address types Resilient IP addressing DNS Manipulation 4 Connection Balancing 4 Virtual IP addressing 4 § Factors that impact your network Network Considerations 4 Virtual Networking 4 § Routing Domain § Choosing a Routing Protocol 5 © 2004 IBM Corporation
IBM e. Server™ Transport Layer Protocols § IP is a connectionless and unreliable protocol that just sends the datagrams it is given over the net § The Transport Layer protocol adds reliability to the Network Layer (IP) **The first three layers of the traditional OSI model (Application, presentation and session) are not impacted by the TL protocols. 6 © 2004 IBM Corporation
IBM e. Server™ IPv 6 § Linux for z. Series supports (IPv 6) when using Gigabit Ethernet and Fast Ethernet 4 See http: //www. ipv 6. org/ if you are unfamiliar with IPv 6 § Differences from IPv 4 include how neighbor discovery, broadcasting and IPSec are implemented § As a user you only need to understand how the addresses are specified 4 128 Bit (giving 6*E 28 addresses per guest) 4 Addresses will be specified in hex format – 3 ffe: 0400: 0280: 0: 0: 1 4 Leading zeros can be omitted – 3 ffe: 400: 280: 0: 0: 1 4 First set of concurrent zeros can be omitted – 3 ffe: 400: 280: : 1 4 IPv 4 addresses can be used within IPv 6 address range – 139. 18. 38. 71 : : ffff: 8 b 12: 2647 7 © 2004 IBM Corporation
IBM e. Server™ IPv 6 Tools § IPv 4 tools versus IPv 6 tools IPv 4 IPv 6 Ping ping 6 ftp ncftp ssh Ssh -6 scp Scp -6 telnet wget Wget -6 tracerroute traceroute 6 Ifconfig <dev> Ifconfig add <dev> 8 © 2004 IBM Corporation
IBM e. Server™ IP address types § Static IP addresses 4 Permanent IP set up by network administrator assigning TCP/IP addresses to identify the clients in your network defined as part of the installation of your Linux system 4 Changes are rarely made, and only done by administrator § Dynamic IP addresses 4 IP addresses are obtained from a Dynamic Host Control Protocol (DHCP) server 4 The address basically leases the address for a limited period of time during which the address is valid 9 © 2004 IBM Corporation
IBM e. Server™ Resilient IP addressing § After establishing physical connectivity for all servers you must insure that all applications within the server will maintain connectivity § Multiple IP addresses have to be tied to a single external interface in Linux for resilient IP addressing to function § Many methods are available to do this, including: 4 DNS manipulation (round-robin, dynamic) 4 Connection balancing 4 Virtual IP addressing 10 © 2004 IBM Corporation
IBM e. Server™ DNS manipulation § Round-robin The DNS can be altered to resolve name requests to multiple IP addresses. This is known as round-robin DNS 4 The DNS zone file lists multiple DNS A records for the one host name, and DNS will issue each address in sequence in response to requests for that name 4 This is not a solution for high availability, since in this model the DNS server cannot respond to the failure of an interface, and will continue to serve the address of a failed interface in response to requests 4 Another issue to consider is DNS caching at the client; this may cause a particular client to continually request service from a non-preferred interface simply because its first request happened to return that address 4 11 © 2004 IBM Corporation
IBM e. Server™ DNS manipulation continued § Dynamic DNS 4 4 4 Allows the DNS server to respond to the state of interfaces and applications Dependant on the factors such as load, the availability of applications and the state of the interface the DNS zone can be on the fly by adding and deleting records One use of DNS would be to update the DNS to add an address record when a new interface is added It is also possible to integrate with network management utilities to add or remove DNS records relative to the amount of traffic being carried by the available interfaces Like round-robin, dynamic DNS is subject to caching of DNS records in the client Dynamic DNS is not yet standardized across DNS server implementations 12 © 2004 IBM Corporation
IBM e. Server™ Connection balancing § A service (performed by z/VM) external to the Linux hosts fields § § § incoming connection requests and serves them to the real servers Because this scenario goes beyond what is needed to merely provide network redundancy, it is used mainly in clustering solutions A simple version of this method could be used by a virtual router to share traffic across interfaces even on a single machine An advantage of this approach is that it eliminates the problems associated with client caching of connection and DNS information due to the fact that the IP address of the distribution server is used for all requests A disadvantage is that in a simplistic design the IP address of the distribution server becomes a single point-of-failure For more information on this kind of design, refer to Chapter 18 of Linux for z. Series and S/390: Distributions, SG 24 -6264 13 © 2004 IBM Corporation
IBM e. Server™ Resilient Network Design 14 © 2004 IBM Corporation
IBM e. Server™ Virtual IP Addressing (VIPA) § VIPA is provided by both z/OS and z/VM to create an address within an IP stack that can be used to isolate applications from the failure of an IP interface or adapter § Applications are attached to the virtual address instead of an interface address 4 Assigns an IP address to a system instead of individual adapters § When a physical interface fails, dynamic routing protocols can reroute traffic over other active interfaces, without operator intervention or outage § Linux provides a dummy network interface that has an IP address which is virtually associated with the physical interfaces of the Linux host and can thus be used to provide a similar feature 15 © 2004 IBM Corporation
IBM e. Server™ VIPA using a dummy interface § Dummy interface is added to the resilient design producing a design that allows almost § § § transparent backup over the failure of any one of the network connections IP address associated with the Linux image is the IP address of the dummy 0 interface With IP routing, incoming traffic is sent to this address using either network interface (dummy or real) If one interface fails, IP routing can forward the traffic via the other interface This works for incoming traffic, any outbound traffic the Linux instance generates is associated with one or the other physical interface TCP/IP sessions that originate from a Linux instance using the dummy driver will fail if the interface those sessions originate on fails 16 © 2004 IBM Corporation
IBM e. Server™ VIPA Setup § Note CONFIG_DUMMY in kernel must be swithced on § Steps 4 Create dummy device – Insmod dummy 4 Assign a virtual IP address (9. 123. 88. 100) to the device – Ifconfig dummy 0 9. 123. 88. 100 4 Enable VIPA on the network devices – Echo add_vipa 4 09 A 4 BC 64: eth 0 > /proc/qeth_ipa_takeover – Echo add_vipa 4 device name: eth 1 > /proc/qeth_ipa_takeover 4 Setup routes to the vitual IP address – Static: • Route add –host 9. 123. 88. 100 gw 9. 123. 88. 10 or • Route add –host 9. 123. 88. 100 gw 9. 123. 88. 11 – Dynamic • Install a routing daemon like zebra (zebra-0. 92. tar. gz ) or gated • Zebra: http: //wiki. cs. uiuc. edu/cs 427/DOWNLOAD/ • Gated: http: //www. unet. univie. ac. at/aix/cmds/aixcmds 2/gated. htm 17 © 2004 IBM Corporation
IBM e. Server™ Factors that impact your inter-network § The routing protocol currently in use in your network (Routing § § Information Protocol (RIP), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIRGP), Border Gateway Protocol (BGP)) The addressing scheme used in the penguin colony How “open” the Linux instances will be The connectivity requirements of customers Isolation from other customers 18 © 2004 IBM Corporation
IBM e. Server™ Network Considerations § Virtual Networking 4 While it is possible to give a number of your Linux instances access to the network directly, this would not be making efficient use of the hardware and the architecture 4 Virtual networking eliminates a large amount of the network infrastructure traditionally present in a server farm 4 Network connectivity is over non-broadcast point-to-point links, which helps make the environment more secure than using physical LANs 19 © 2004 IBM Corporation
IBM e. Server™ Virtual Networking § A network perspective of a virtual routing environment: 4 The devices and links between virtual servers are functionally identical to real ones 4 Since many basic packet-filtering tasks can be performed in your Linux routers, you can avoid the need for a lot of external firewall equipment except for highsecurity applications § Virtual networking from a processing perspective 4 Routers and links are virtualized by z/VM, and share the CPU consumption, this means that virtual network traffic will cost real cycles in your z. Series processor 4 Each virtual interface defined will require buffer space, this quickly adds up over all the machines 20 © 2004 IBM Corporation
IBM e. Server™ Routing domain § § A routing domain is a group of networks that share routing information Routing domains can be used to control the flow of routing information in a large Network, or between networks. Communicating between domains: 4 You want to allow connectivity as required, without exchanging topology information 4 An exterior gateway protocol is used in this role 4 Routers on either side inform each other about the networks that can be reached, without exchanging the detailed information provided in interior routing protocols 21 © 2004 IBM Corporation
IBM e. Server™ Choosing a routing protocol § Poor design of the interface between a penguin colony and the outside would could interfere with communication all over the network, planning is key § One option is to use the same routing protocol inside and outside the colony giving you uniformity across the whole network 4 Usually this can be applied in smaller networks, or where the consistency of using a single protocol is desirable § A second method is to use a different protocol inside the penguin colony from the one being used outside § The third method is to use an exterior gateway protocol between the penguin colony and the rest of the network 22 © 2004 IBM Corporation
IBM e. Server™ Linux Networking § Configuration files § Important Network Files § Network Daemons § Trouble Shooting § Accessing Data and Applications 23 © 2004 IBM Corporation
IBM e. Server™ Configuration files § Hosts file: 4 Holds a text database consisting of the host names and IP addresses of the hosts your Linux for z. Series § § § § system will need before being able to contact its Domain Name Server (DNS) 4 The database is read to resolve these host names into their IP addresses 4 This is not a very scalable method, so most move to DNS Services file: 4 Names the networking services that your machine provides to other hosts on the network, identifying the port and host-to-host protocol that the service uses Protocols file 4 Names the TCP/IP protocols that your Linux for z. Series system recognizes and assigns a number to each The HOSTNAME file 4 Holds your machine’s name defined during installation 4 If you named your machine irock. linux. com, your hostname file will contain: irock inetd. conf file 4 This file is read by inetd, the TCP/IP super server 4 Each line describes how inetd handles one service Network script This script is found in the /etc/rc. d/init. d/ directory and is called from the main system boot script, rc. sysinit Ensures that commands are executed to activate your TCP/IP networking resources, which include connections, interfaces, and daemons Note: location of this script will vary dependant upon the distribution 24 © 2004 IBM Corporation
IBM e. Server™ Important Network files § /etc/gated. conf Configuration for gated daemon 4 Used only by the gated daemon 4 § /etc/gated. version 4 Contains the version number of the gated daemon 4 Optionally used by the routed daemon §. /etc/gateway § /etc/networks Lists names and addresses of networks accessible from the network to which the machine is connected 4 Used by route command. Allows use of name for network (my network) 4 § /etc/protocols Lists the currently available protocols 4 See the NAG (Network Administrators Guide) and man page 4 C interface is getprotoent 4 § /etc/resolv. conf 4 Tells the kernel which name server should be queried when a program asks to "resolve" an IP Address 25 © 2004 IBM Corporation
IBM e. Server™ More Networking Files § /etc/rpc 4 Contains instructions/rules for RPC, which can be used in NFS calls, remote file system mounting, etc 4 The file system to be exported (NFS) and permissions for it. 4 Translates network service names to port number/protocol Read by inetd, telnet, tcpdump, and some other programs There are C access routines § /etc/exports § /etc/services 4 § 4 /etc/inetd. conf 4 4 4 Config file for inetd See the inetd man page: Holds an entry for each network service for which inetd must control daemons or other servicers Note that services will be running, but comment them out in /etc/services so they will not be available even if running. Format: <service_name> <sock_type> <proto> <flags> <user> <server_path> <args> § /etc/sendmail. cf 4 The Mail program sendmail's configuration file 4 Indicates NETWORKING=yes or no Read by rc. sysinit at least. /etc/sysconfig/network-scripts/if* Red Hat network configuration scripts §. /etc/sysconfig/network 4 4 26 © 2004 IBM Corporation
IBM e. Server™ Network daemons § Inetd daemons Is a generic listener or super-server named Inter. NET services daemon ( inetd ) 4 It is a server designed to listen on many well-known ports for incoming connection requests 4 When a connection request is received, the socket call is accepted and then inetd forks and executes the appropriate server 4 Reduces system load by only running applications when they are needed 4 § Telnetd 4 4 4 Telnetd is the server daemon that handles telnet connections It is activated by inetd whenever a datagram arrives at the telnet port 23 and if the service is activated in inetd. conf It negotiates the parameters of the connection, then it returns control of the port to inetd It allocates a pseudo-terminal for a client, then creates a login process that runs the slave side of the pseudo-terminal When the master side starts up, it sends options to the client for setup § Syslogd Takes care of logging in order to allow you to trace and track any problems you might be having in your Linux network 4 For more on system logs see page 203 of the Linux on s 390 Redbook 4 27 © 2004 IBM Corporation
IBM e. Server™ Troubleshooting § Ping command 4 Sends out an echo request to determine if a host is accessible 4 Useful for troubleshooting problems in network and for determining which resources are available 4 Syntax: ping [options] host § The netstat command 4 Displays the status of the network 4 Shows TCP/IP connections, gateways, network clients, and routing info 4 Syntax is as follows: netstat [options] 4 -r for example shows your kernel routing table § The ifconfig command 4 Used to activate or shut down an interface 4 To use it as a reporting tool use the ifconfig [interface] option, it would give you a complete listing of the active interfaces on your machine 4 To show you the options for actually setting up an interface use ifconfig interface [aftype] options | address. . . § The route command 4 Used by the root user to manipulate the Linux kernel’s routing table 4 The kernel uses its routing table to determine which interface has access to which hosts 4 Note: because this command manipulates the network routing table of the Linux kernel, it should only be used when you know what you are doing 28 © 2004 IBM Corporation
IBM e. Server™ Access to data and applications § Telnet command 4 Allows you to connect to a remote machine and log on just as if it were your local machine 4 Can also be used to connect to remote machines and use programs like ftp 4 The telnet program can be invoked with either an IP address or the name of the host you are § rlogin trying to connect to 4 Allows you to log in to a remote host § rsh 4 Allows you to execute a shell command on a remote host § rcp 4 Allows you to copy a file to or from a remote host § Ssh (Secure SHell): openssh 4 Prevents any sort of security leaks, such as the sending of clear text passwords 4 Openssh is an open source version of ssh 4 You log into the remote host, You will be prompted to enter the given user’s password, 4 The session is authenticated between your machine and the remote host using encryption, you are given your own encrypted transport between you and the remote host (i. e. everything sent over that connection will be encrypted from end to end) 4 Also provides compression of all data, thus you also get much faster transportation 29 © 2004 IBM Corporation
IBM e. Server™ Networking Connectivity Options § Open Systems Adapter (OSA) 4 § § § § OSA Express Queued Direct I/O: (QDIO) Channel-to-channel (CTC) Virtual CTC (VCTC) NIC and Guest LANs (Local Area Networks) Inter-User Communications Vehicle (IUCV) Common Link Access fo r. Workstation (Claw) Hiper. Sockets 30 © 2004 IBM Corporation
IBM e. Server™ Open Systems Adapter (OSA) § OSA is a network card for z. Series mainframes § Linux can utilize Ethernet, Fast Ethernet, Gigabit Ethernet and Token Ring OSAs § OSA-Express, is the newest version of the OSA, it provides: New Gigabit Ethernet interface, and improved Fast Ethernet interface 4 Queued Direct I/O (QDIO) mode, which uses the Self-Timed Interconnect (STI) bus to provide memory-to-memory transfer of network traffic, dramatically increasing throughput 4 IP Assist feature (available in QDIO mode), which offloads adapter processing from the host TCP/IP stack 4 Dynamic OSA Address Table (also in QDIO mode only), which eliminates the need to predefine IP addresses 4 Increased number of IP addresses per port available in OAT: from 16 to 512 on G 5/G 6 to 2048 on z. Series, and a maximum of 240 entries per OAT 4 Increased number of subchannels available 4 LCS support for TCP/IP when configured in non-QDIO mode § OSA creates a direct path to the “outside world” where required, however not all members of a large penguin colony can connect to it § For OSA to give all servers network connectivity virtual networking must be implemented 4 31 © 2004 IBM Corporation
IBM e. Server™ OSA-Express § In QDIO mode the card can communicate directly with the Central Processing Complex (CPC) using data queues in memory and utilizing Direct Memory Access (DMA) § This proves to be much faster than previous technologies. § You have different options for the adaptor to use 4 All OSA 2 cards use the lcs. o driver 4 OSA-Express fast Ethernet cards can use the lcs. o driver in non-QDIO (or OSE) mode, or the combination of the qeth. o and qdio. o drivers in QDIO (or OSD) mode 4 OSA-Express Gigabit Ethernet cards only run in QDIO therefore they must utilize the combination of the qeth and qdio drivers 32 © 2004 IBM Corporation
IBM e. Server™ OSA Address Table (OAT) § OSA’s design allows it to be accessed by multiple LPARs or z/VM guests with different IP address, who are at the same time part of the same physical LAN (using shared mode) § In shared mode, the OAT is used to determine which z/VM guest (or LPAR) will receive the incoming packet § To ease definition work required and to simplify configuration 4 A particular z/VM guest or LPAR can be defined to the OSA as the primary router to which all IP packets arriving from the network that do not have a corresponding specific OAT entry will be sent 4 A secondary router can be defined to receive packets should the primary fail 4 The IP address used in this process is the destination IP address of the packet, which may or may not be the IP address of your router system. If the packet is destined for one of the Linux images in your penguin colony, then it will be the IP address of that system and not the router’s address 33 © 2004 IBM Corporation
IBM e. Server™ Packet path through the OSA 34 © 2004 IBM Corporation
IBM e. Server™ Multiple OSAs per Linux Router § Creates a more high-availability configuration § Requires connecting each OSA to a different LAN, with redundant § § network connectivity Provides greater bandwidth to your penguin colony, in which case you can have these OSAs connected to the same LAN With multiple routers you need to be aware that the way the Linux kernel responds to ARP requests may cause connectivity to fail if you are not using primary routers in your OSA’s If you are not defining your Linux router as the primary default entry in the OAT, you must turn may turn this response feature off However this behavior has efficiency and availability advantages 4 It makes sense for the first adapter to receive the ARP request to respond, it is possibly less busy than other adapters 4 This saves the time and energy of waiting until the request is received at the correct adapter 4 Also this helps if there is a physical cabling problem with the other adapter 35 © 2004 IBM Corporation
IBM e. Server™ QDIO mode § QDIO mode This mode gives high-speed (up to 1 Gb/s on the z 900) operation through direct use of the STI (self-timed interconnect) bus 4 It also provides a facility which allows the operating system to dynamically update the adapter’s OAT using an “out-of-band” signaling path between the driver and the adapter 4 OAT no longer has to be built manually § OAT update from z/VM TCP/IP or CS/390 4 QDIO support in VM TCP/IP and Communications Server for OS/390 provides updates to the OAT for any configured interface. This means that not only is the IP address for the OSA adapter itself added, but any other interfaces, as well 4 This support is required particularly for OS/390, where the use of Virtual IP Addressing (VIPA) required the VIPA address for a stack be added to the OAT 4 There are no updates for addresses that are not connected to the stack, however. In the case of an IUCV connection under VM TCP/IP, for example, the IP address of the local end of the connection is added, but the remote end is not. 4 36 © 2004 IBM Corporation
IBM e. Server™ QDIO mode continued § OAT update from Linux 4 Under Linux, the qeth driver will only add the OSA’s own address to the OAT. 4 No other addresses on the Linux system are added 4 However, the qeth driver supports an interface through the /proc file system which can be used to manually add an OAT entry against this instance of the qeth driver 4 This would allow logic to be added to the network configuration scripts for CTC and IUCV interfaces 4 When the interfaces are configured, the script would additionally invoke the qeth driver to add the peer IP address for the link to the OAT § Sharing an OSA 4 With recent versions of the LCS (LAN channel station) driver it is okay to share OSA between Linux and your operating system although care must be taken to when this is done 37 © 2004 IBM Corporation
IBM e. Server™ Channel-to-channel (CTC) § CTC is a point-to-point connection, using either a real channel interface or a virtual § § § channel provided by z/VM Multiple CTCs can be configured, allowing connectivity to multiple points in the environment The link-layer protocol used for TCP/IP over CTC is very similar to Serial Line Interface Protocol (SLIP) , an early connection method used over dial-up communications lines By using the same link protocol, z. Series operating systems allow a Linux instance to connect not only to another Linux, but also to a z/VM or z/OS TCP/IP stack The CTC driver can be compiled as part of the kernel, or a module (ctc. o) CTC with Linux has proven to have high reliability; but it cannot be dynamically configured Also, the CTC driver becomes unstable if the channel is interrupted for any reason (that is, if the other end of the link is brought down) 38 © 2004 IBM Corporation
IBM e. Server™ VCTC § z/VM Virtual CTC (VCTC) allows a device pair to be configured to link devices on two guests together 4 The linked devices then act exactly like a physical CTC, with z/VM carrying the network traffic internally between the two guests § A VCTC connection is really a software connection between two z/VM guests on the same z/VM systems § A virtual connection is much faster than physical connection 39 © 2004 IBM Corporation
IBM e. Server™ NIC and Guest LANs § NICs 4 Are used to connect to a local area network (LAN) 4 Examples of NIC protocols supported by z/VM are Hiper. Sockets and OSA-Express QDIO mode – Real Hiper. Sockets connect server images in separate LPARs on a Hiper. Socket LAN – Virtual Hiper. Sockets connect server images in virtual machines – Like with virtual QDIO NICs data is transferred at near memory speeds as a guest is connected to the Virtual LAN (Guest LAN) inside z/VM § Unlike real connections there is no predefined limit on the number of virtual Hiper. Sockets, QDIO connections or Guest LANs that can be created § Unicast, multicast and broadcast communciation is possible in a guest LAN § Types of Guest LAN 4 System Guest LANs exist independently of active logged on guest 4 Guest LANs associated with a specific z/VM guest, these LANs will exist only as long as the guest is active 40 © 2004 IBM Corporation
IBM e. Server™ Inter-User Communications Vehicle (IUCV) § IUCV is software that provides a virtual communication link which is functionally similar to VCTC, but does not involve channel I/O § It is available only under z/VM (internal interface) § IUCV can be used only to connect between Linux images or z/VM TCP/IP stacks in a single z/VM system; however a Linux program running in one z/VM guest to communicate with another Linux program running in another z/VM guest, or with a program or even with itself § Some prior planning is required to ensure that guests have the right directory authorization to make IUCV connections (need R/W access to these directories) 4 The system administrator may not want to give kernel level access to all users, but need to ensure that the root id can make necessary connections § Communication takes place over a predefined linkage called a path § IUCV support code has been added to the kernel, and like CTC can be compiled either as part of the kernel or as a module § Configuration issues function similarly to CTC, as far as Linux is concerned it is still a point-to-point TCP/IP connection § Performance is actually better than that of VCTC due to the fact that IUCV does not have to emulate channel I/O § IUCV has now largely been replaced by Hiper. Sockets 41 © 2004 IBM Corporation
IBM e. Server™ Common Link Access to Workstation (CLAW) § CLAW is used to connect to the Cisco Channel Interface Processor (CIP) card, it is therefore § § an external interface (allows Linux instances to communicate outside the boundary of the z. Series machine they are running in) Allows installations using channel- or ESCON-attached Cisco routers to link to Linux systems directly, in order to decrease the routing path between the network and the Linux instance. An experimental driver for CLAW has been written by UTS Global, but has not been extensively tested An alternative to using this driver would be to use TCP/IP on z/VM to link to the hardware, then use IUCV to communicate between Linux and z/VM (this is illustrated in “z/VM TCP/IP as a virtual router” Other S/390 TCP/IP devices 4 There a number of other connection types supported by z. Series hardware, including: Channel Data Link Control (CDLC), used to connect to the IBM 3746 Multiprotocol Controller, Multi Path Channel (MPC), enhanced protocol used for OSA (non-QDIO) and, host-host links, ATM and FDDI OSAs, HYPERchannel A 220 devices, SNALINK (TCP/IP access over SNA to 3745) 4 While Linux does not natively support these connections, it is possible to use a z/VM or z/OS system to connect to them, and then use CTC or IUCV to link to the Linux system 4 In some cases it may be possible to reconfigure the hardware to provide direct connectivity to Linux. For example, if you are using the MPCOSA device type for communication with an OSA in z/OS, you could create an LCS definition for use by Linux. fds 42 © 2004 IBM Corporation
IBM e. Server™ Hiper. Sockets § Rather than giving the Linux guest a real connection this provides a virtual connection § Hiper. Sockets were developed to provide a highly available, high-speed network connection among mainframe operating systems, and Linux distributions with such support § Are utilized in a z/Linux environment to connect a Linux guest to another Linux guest on the same z/VM system (this can work with other supported operating systems such as Unix, z/OS etc. ) § This uniquely integrated any-to-any TCP/IP network yields a list of benefits not achievable by grouping servers in a z. Series server interconnected by external networking technology 43 © 2004 IBM Corporation
IBM e. Server™ Hiper. Sockets function § Provides the fastest TCP/IP communication between consolidated Linux, z/VM, and z/OS virtual servers in a z. Series by allowing virtual machines and logical partitions (LPARs) to communicate internally over the memory bus using the internal-queued-direct (IQD) channel type in the z. Series (communication at memory speeds) § Provides a higher level of network availability, security, simplicity, performance, and cost effectiveness than an external single server solution communicating across an external TCP/IP network § The z 900 supports up to 4 real Hiper. Sockets, the z 990 extended that to 16 which is the new microcode limit 44 © 2004 IBM Corporation
IBM e. Server™ Hiper. Sockets advantages § Uses an adaptation of the QDIO (Queued-Direct Input/Output) high§ § speed I/O protocol Operates with minimal system and network overhead Eliminates the need to utilize I/O subsystem operations and the need to traverse an external network connection to communicate between LPARs Offers significant value in server consolidation by connecting may virtual servers without the cot of external wiring Provides an extremely secure connection 45 © 2004 IBM Corporation
IBM e. Server™ Networking in a z/VM Environment § Overview § TCP/IP communication § Diagram: z 900 running with z/VM § Implementing Hiper. Socets on z/VM Guest LAN § Diagram: Hiper. Sockets in use § Virtual Routers § Simple Network IPL (sn. IPL) *helpful tool 46 © 2004 IBM Corporation
IBM e. Server™ Networking in a z/VM: Overview § z/VM control Program can access any of the physical hardware devices mentioned (OSA, CTC, etc) when they are defined as shared rather than dedicated to one guest 4 Network must be designed so that no unauthorized access to data or resources is possible (system administrator must set up permission levels for all possible users) 4 Its best to set up a separate network with secure access for system administration tasks (since this will require many more privileges) § When connecting a Linux server running in an LPAR on top of z/VM to another Linux (even in a different LPAR) a shared OSA port can be utilized 4 If both operating systems support this type of connection, Hiper. Sockets can be used 47 © 2004 IBM Corporation
IBM e. Server™ Networking in a z/VM: TCP/IP Communication § For TCP/IP between two virtual Linux servers running in the same z/VM system (z/VM running in an LPAR or on the native hardware) you can use the other methods mentioned 4 VCTC 4 IUCV 4 z/VM Guest LAN: Hiper. Sockets § All methods are secure from third party eavesdropping since there is no external line 4 However, the connections are only as secure as the connected OS using them 48 © 2004 IBM Corporation
IBM e. Server™ z. Series 900 machine with z/VM running in an LPAR 49 © 2004 IBM Corporation
IBM e. Server™ Implementing Hiper. Sockets function on Guest LANs § z/VM supports the Hiper. Sockets function on Guest LANs, for interconnecting virtual machines § z/VM Guest LAN support works similar to the way that z/VM emulates channel -to channel adapters for communication among virtual machines without the need for physical media (such as ESCON, FICON, or other channel to channel connections) § Every individual guest LAN can be used by a group of virtual machines to communicate among themselves, independent of other groups of virtual machines on other Guest LANs provided that the guests have Hiper. Sockets support 50 © 2004 IBM Corporation
IBM e. Server™ Hiper. Sockets in use 51 © 2004 IBM Corporation
IBM e. Server™ Virtual Routers: § Using Linux as a Virtual Router Benefits Provides an efficient routing engine 4 Linux has advanced routing capabilities, including Netfilter 4 Ability to build a thin, “routing only” kernel to maximize performance 4 When adding new members to the penguin colony, however, the CTC and IUCV drivers must be unloaded in order to add the new connections. This is disruptive to existing connections (and in the case of the CTC driver, may cause other servers to be restarted). In addition, the scalability of the CTC and IUCV drivers is not extensively proven 4 § z/VM TCP/IP as a virtual router This addresses the availability issue of the Linux router, because new devices can be added on the fly using OBEYFILE 4 z/VM as a “first-level” router can provide a more proven method of providing connectivity to Linux using unsupported or experimental network hardware for which the Linux driver may still be considered experimental 4 The TCPIP OBEY command in z/VM uses the config statements contained in a file known as an OBEYFILE to allow the dynamic alteration of a running TCP/IP stack 4 It is also possible to create a layered approach utilizing both Linux and z/VM for routing 4 52 © 2004 IBM Corporation
IBM e. Server™ Virtual failover solutions § With z/VM controlling the hardware, it can be considered a single point of failure § Create a failover system in the event that z/VM suffers an outage 4 You may want to create a duplicate image 4 You may duplicate z/VM on another LPAR 4 You may use a duplicate machine 53 © 2004 IBM Corporation
IBM e. Server™ Simple Network IPL (sn. IPL) § Interactive tool for remote control support element functions such as: Boot Linux for z. Series in LPAR mode 4 Send and retrieve OS messages 4 Deactivate an LPAR 4 § Runs under Linux § Uses a network management API that uses SNMP (simple network management protocol) to send and retrieve data § Can be found at developer works: 4 http: www 10. software. ibm. com/developerworks/opensource/linux 390/us eful_add-ons. shtml 54 © 2004 IBM Corporation
IBM e. Server™ Conclusion § Static IP addresses are for the most part permanent and are set up by the network administrator. Dynamic IP addresses can change each time a machine is booted and are obtained from the DHCP server § Configuration files contain the parameters and devices that you need to give your system connectivity, among them are host files, services file, protocols file the hostname file and the inetd. conf file § The network script is also important as it ensures that commands are executed to activate your TCP/IP networking resources § Users may access their servers, data and applications through different methods dependant on security needs and individual environments. Among the options are the telnet command, rlogin, rsh, rcp and ssh 55 © 2004 IBM Corporation
IBM e. Server™ Conclusion § In your Linux on z. Series environment there are several options you have to maintain connectivity, both to your external world with OSA and CLAW and internally within the images of your machine using VCTC, IUCV or Hiper. Sockets § Virtual connections such as those used by IUCV and Hiper. Sockets and Guest LANs provide huge cost savings as they reduce the amount of physical wiring that needs to be purchased and eliminates all possible reductions in availability caused by wiring problems and offer huge advantages in speed since most operate at close to memory speeds. Hiper. Sockets in particular eliminate the need to utilize the I/O subsystem operations and the need to traverse an external network connection to communicate between LPARs § Also with virtual connections you don’t have the predefined limits on the number of connections you can create that may hinder growth with real connections. § However these virtual connections obviously only work within your z. Series machine, connections to the outside world still must be created reducing some of the security benefits of keeping all communication within the machine. 56 © 2004 IBM Corporation
IBM e. Server™ Conclusion § Either Linux or z/VM can be used as virtual routers, to reduce the need for physical networking devices. Using z/VM gives the added benefit of allowing you to add new devices on the fly § To ensure that all applications within the server maintain connectivity you need to set up a resilient IP addressing scheme. This can be achieved by DNS manipulation, connection balancing or Virtual IP addressing § From a network perspective, virtual routing is identical to physical networking. The Linux routers easily perform the functionality of most external firewall equipment and physical routers § From a processing perspective however, new things need to be taken into account when virtual networking takes place. All routers and links created are sharing the CPU resources available. Meaning that you end up paying for virtual network traffic in cycles on your z. Series processor 57 © 2004 IBM Corporation
IBM e. Server™ References § For more on DNS see Chapter 18, “Domain Name Service (DNS)” on page 349 of Linux for s 390 (SG 24 -4987 -00 ISBN 0738419141) 4 See Chapter 5, “Native S/390 installation and operation of Linux” on page 45 4 Chapter 6, “z/VM installation and operation of Linux for S/390” on page 85. § For good insight into the way that TCP/IP is implemented in Linux http: //kernelnewbies. org/documents/ipnetworking/linuxipnetworking. html § Linux on IBM z. Series and S/390: ISP/ASP Solutions (SG 24 -6299 -00 ISBN 0738423521) 4 Chapter 3, Virtual Server Architecture 4 Chapter 4, Networking a penguin colony Chapter 11, Network Infrastructure design § Look in the Linux Commands folder for common networking commands for both Linux and z/VM 4 58 © 2004 IBM Corporation
- Slides: 58