9.5 Setting up for secure and efficient IO
9.5 Setting up for secure and efficient I/OA Linux image needs all three resources of a computer system: CPU, memory, and I/O. Let us present a couple of methods that can give you value in your setup. Resource sharing for Linux guests under z/VM is one of the strong points of the Linux-on-the-mainframe solution. For a guest, you can define the number of CPUs or parts of CPUs it should have, as well as how much memory it should have. In contrast to other solutions (based on individual real processors), a decision to give a guest more CPU capacity does not have to be expensive. Using the guest directory definition, administrators can change resources allocated to a guest in a matter of minutes. Compared to over-configuring real hardware (such as CPUs), z/VM allows you to simply change the definition to either add more or take some away. Resources taken from one guest can easily be made available to others. The third resource, I/O, can also be set up to be shared in different ways. I/O on the mainframe is set up by defining the paths, the devices, and the relationship of devices to paths to the mainframe hardware, to z/VM, and to Linux. The mainframe accesses devices by means of channel paths. The hardware looks only for those devices that are defined to it in a configuration file called IOCDS (I/O configuration data set). The definitions for all LPARs and the number of LPARs are defined in the IOCDS file. If a device and its path are not defined in the IOCDS, the device is invisible and inaccessible to the hardware and all operating systems and programs that run on the LPAR, even if there is an actual, physical cable connection. If a device is defined in the IOCDS, it will be visible and usable as long as it is physically present. A device can be defined in the IOCDS file and not be physically present without causing any errors. In fact, it is common practice to overconfigure the I/O paths to support availability and future growth. For example, you can define a fiber channel with a new set of ESS storage in the IOCDS. You can then later "hot-plug" the ESS without having to change the configuration file. z/VM can see the devices on all channel paths known to its LPAR (or the machine, if z/VM runs natively). A z/VM guest can see only those devices that z/VM defines to it. These definitions can be changed dynamically from z/VM. z/VM can also split the real devices into smaller virtual devices and control the guest's access at the level of the virtual devices. On Linux, you have two possibilities. One alternative is to use the auto-detect capability. Linux attempts to access all devices it can find. Thus, if there is an actual cable connection to a device, and Linux has a channel path that can access it, the device will be accessed. In an environment where resources are heavily shared, you might want to avoid this. For instance, you can use the z/VM guest setup to rule out what Linux should not access. The alternative is to instruct a Linux image to look only for specific devices. Linux is then unable to see any other devices, even if the hardware definitions and z/VM have made them available. It is possible to overconfigure the paths for the hardware, overconfigure z/VM, and (in the guest definition) restrict Linux' access to devices. By constraining each of the guest's definitions to only the devices actually needed, you effectively protect the data on the devices from misuse by other guests. I/O definitions for a guest can be changed dynamically. 9.5.1 Booting and automatic findWhile Linux on the mainframe gives you great flexibility when configuring channels and devices, it may be helpful to know something about how Linux assigns devices so that you can use the flexibility to your advantage. Unless the kernel parameter file contains an entry for disk or minidisks, Linux on the mainframe assigns disk devices (disks and minidisks) based on the order in which the disks are found at boot time. If there is no such entry, the disks are ordered according to the subchannel number allocation that takes place at boot. To be on the safe side, it is strongly recommended that you list the disk and minidisks that you want Linux to use in the kernel parameter file. This assures a well-known naming convention that commands and applications can safely assume. Here is an example of a disk entry in the kernel parameter file: dasd=200 mdisk=201,202,203 root=/dev/mndc ro This entry ensures that dasda maps to disk 200, mnda maps to minidisk 201, mndb to 202 and mndc to 203. Also, mndc (203) is where the root file system will be mounted. With this entry in the kernel parameter file, these allocations are assured at every boot. Without it, you could have unpredictable allocations, especially if you (or someone else) change the I/O configurations in Linux. 9.5.2 Network considerationsThe network setup is central to the design of the solution. Linux on the mainframe offers two unique values for network setup.
9.5.3 File system considerationsAvailability of a system involves two key aspects: avoiding system failures and if the system does fail, ensuring a quick recovery from the outage. The file system recovery can add a significant amount of time to the recovery process. Several different file systems are available on Linux. Broadly speaking, file systems fall into two distinct categories: conventional and journaled. Conventional file systemsA conventional file system must be contained within one physical device. This type of file system uses a delayed write protocol which implies that recovering the file system after an outage requires scanning the disk and reconstructing the file system. The advantage of conventional file systems is that these are relatively fast in I/O processing. One down side is that these file systems typically limit the file size to the device capacity. Additionally, if a check or repair of a conventional file system were necessary, the process can take a very long time if it is on a large disk. ext2 is an example of a conventional file system. With the Linux 2.4 kernel, it is the de facto standard Linux file system. (Some distributors are now changing the default file system from ext2 to the journaled file system ext3.) Journaled file systemsA journaled file system keeps a record of all changes that are made to data held on the file. In the event of a software failure or any data integrity problems, recovery and repair can be completed quickly using the journal instead of restoring by hand. For example, restoring a file system to a consistent state takes seconds or minutes, rather than the hours or days it can take with a large non-journaled file system. However, journaled file systems do incur a performance hit because all changes to the data must be recorded. Examples of journaled file systems are:
Other file systemsThere are a great many other types of file systems available. Some of the more common are:
|
EAN: 2147483647
Pages: 199