14.4 Data, policies, and tools
| Enterprises know how vital their business data are to them. Accordingly, most companies use policies (and an SLA) to control how its data are handled. Because there is no universally valid answer to the question of which policy and SLA are suited to the data that are required and generated by an application on Linux, let us turn to our hypothetical companies to explore some interesting possibilities for Linux on the mainframe. 14.4.1 ISPCompany data managementISPCompany, as an ISP and outsourcing partner, is the keeper of the corporate and personal data of a large number of clients. ISPCompany faces the challenge of isolating different clients' data and of catering to a wide spectrum of needs for backup, disaster recovery, and space management. As the guiding principles for its data management, ISPCompany follows these policies:
ISPCompany maintains two geographically distant sites, each with a zSeries machine. Our discussion focuses on the primary site, where ISPCompany manages a total of 14 terabytes of data. The primary site is illustrated in Figure 14-7. By far, most of the data is client data (Web content, mail, applications, and various business data). A much smaller amount is ISPCompany's own data. This includes its production capital (master copies of its z/VM and Linux operating systems, configuration files, the middleware and applications it offers to clients, and the Linux images it uses to manage itself). The rest is ISPCompany's business data (accounts receivable, payable, in-house developed code, the log files it uses for accounting, and other minor proprietary items). Figure 14-7. ISPCompany storage devices and connections at its primary site
ISPCompany devicesAs illustrated in Figure 14-7, ISPCompany uses two IBM TotalStorage Enterprise Storage Server (ESS),[34] ESS1 and ESS2, to store 14 terabytes of data at its primary site. Approximately 8 terabytes reside on ESS1 with 6 terabytes on ESS2. Each ESS has about 500 gigabytes of empty disk space. There is redundancy for all critical parts (such as control units) to eliminate single points of failure.
To cope with the massive amount of data for archiving and backup and restore purposes, three IBM TotalStorage LTO Ultrium tape libraries are available. Each ESS is divided into two sections: one that acts as a SAN and another with direct-attached virtual 3390 disk devices. The SAN on ESS1 is owned by the mail servers. Only the mail servers and a trusted ISPCompany Linux image that handles backups can access this SAN. The SAN on ESS2 provides storage for a client of ISPCompany's outsourcing section. The client has made special arrangements with ISPCompany to be able to experiment with a SAN. No one but this client's images have access to the SAN. All further security aspects are left to the discretion of the client. Some clients of the outsourcing section have their own devices that are accommodated in their respective client cages. Clients can also include in their contract the ability to attach to devices in the ESS2. ISPCompany data securityISPCompany has to meet the challenge of protecting its many clients from each other, while assuring that all clients have access to their own data. To isolate data for medium and large client accounts, ISPCompany uses dedicated disks that can be accessed only from the owners' Linux images. ISPCompany uses z/VM as the place from which to do the physical data security management. No client has access to z/VM. This means that accounts which control their own Linux images cannot boot them directly. Instead, such clients send a message to a z/VM tool. The tool checks if the request originates from an authorized source. If so, the tool performs the requested IPL and logs it for auditing purposes. The thousands of e-mail accounts do not get pre-allocated dedicated disk space. These customers access their data through the mail server instead of directly. ISPCompany uses the mail server's security to protect the data. In keeping with its privacy policy for client data, ISPCompany logs each occasion in which an ISPCompany employee accesses client data. Accessing client data is permissible only when necessary for debugging and is mostly restricted to viewing diagnostic data. Breach of these rules is seen as serious enough by ISPCompany to warrant dismissal. ISPCompany data sharingThe large accounts in the outsourcing business have their data on dedicated disks that can be accessed only by a client's own images. ISPCompany's tools see only disks and partitions, not file systems and files, unless the tools actually log in to the client's image. Medium-sized accounts in the outsourcing business use standard Linux images and share (read-only) the respective disk with Linux code libraries. The same rules apply to some of the standard applications. The unique data of these accounts are kept on dedicated disks. ISPCompany backup and restoreThe clients of ISPCompany's outsourcing services have an enormous amount of data to back up. To minimize disruptions to these clients' businesses and stay within acceptable backup windows, ISPCompany uses a carefully devised scheme:
ISPCompany divides the data into three regions, each attended to by an IBM Tivoli Storage Manager on a Linux image. Agents on the clients' Linux images determine which files to back up. Each manager schedules and coordinates the different backup operations across the ISPCompany clients within its region. To cope with the workload backups for the three regions ISPCompany usually performs backups simultaneously. The mail server's data are backed up only to protect the mail that has not been replicated to the users' mail clients. The responsibility for backing up mail that has been replicated to a user client is transferred to the user. Backups are taken every day and kept for a month. The medium and large business accounts can directly request a restore from the responsible Tivoli Storage Manager. The manager performs an authentication and an authority check to determine if a request is legitimate before it routes the request to the tape library. ISPCompany data handling for disaster recoveryEvery month, ISPCompany uses a z/VM tool, DASD Dump/Restore (DDR), to dump to tape all of the data that it has earmarked for disaster recovery. The tape device is a high-speed IBM LTO Ultrium. DDR is invoked from a REXX script on z/VM, where the script defines which disks are to be copied. Incremental backups of the disaster recovery data are taken daily. Because these increments do not map to complete devices, DDR is not used. After the data are written to tape, the tapes are removed and sent to the second ISPCompany site for safekeeping. The secondary site acts as a recovery site. Disaster recovery tapes are exchanged between the sites so that each site keeps the recovery tapes of the other site. Each z900 has an idle LPAR that is ready to be IPLed with a z/VM system laid out on disks. At the expense of a mere three 3390 devices' worth of storage for the z/VM system data and with no extra hardware, a z/VM for the most essential ISPCompany and client Linux images has been deployed, ready for IPL, at the recovery site. Resumption of full services depends on the scale of the disaster. Resumption also involves special agreements for fast delivery of replacement machines and devices to a contracted site. ISPCompany database managementISPCompany uses DB2 databases, both for its own purposes and on behalf of its clients. ISPCompany performs backup for all databases that it controls. It uses Tivoli Storage Manager to drive the backups. Clients who have opted to manage their databases themselves can schedule these activities from their Linux images (for example, using the cron daemon). ISPCompany space quotasISPCompany can control disk space usage at the image level and at the Linux user level. At the image level, ISPCompany uses z/VM disk storage virtualization as a means of providing storage to clients who use the company's outsourcing facilities. A Linux image under z/VM is given access to the amount of storage agreed to in the respective SLA. Space can be allocated as full disks or as z/VM minidisks. To limit the storage of individual Linux users, the Linux kernel can be installed with a quota function. Most of the Linux images which ISPCompany provides to its clients and the Linux images which ISPCompany maintains for its ISP clients use the Linux quota facility. 14.4.2 StoreCompany data managementStoreCompany has been running its department store chain with the support of a z/OS Parallel Sysplex at each of its major sites. At the site we are going to examine, StoreCompany had been using hundreds of 3390 disks for storing its data. StoreCompany has also recently purchased an IBM TotalStorage Enterprise Storage Server (ESS) with a capacity of 1.25 terabytes. The challenge for StoreCompany is to experiment with its new Linux project without endangering the integrity of its corporate data. StoreCompany responds to this challenge (and largely sidesteps the overhead for managing data for its new Linux project) by adopting a policy that uses existing procedures and tools.
StoreCompany devicesStoreCompany has approximately 900 gigabytes of data, most of which is owned by its z/OS sysplex. There is enough spare capacity for operations, plus some room for future expansion. Besides the ESS, there are the older 3390 disks and a tape library for backup and restore (Figure 14-8). Figure 14-8. StoreCompany storage devices
StoreCompany keeps the z/OS data on the ESS. To conveniently provide a separate space for the new Linux project, StoreCompany places the system data for these Linux images and the local data for the new Linux application on some of the spare 3390s. StoreCompany data integrityThrough its policy that the new Linux application must not be responsible for business data, StoreCompany eliminates any new risk of losing data. The application on Linux does not generate new data. The application can feed data back to the online sales application on z/OS only through the existing order entry process and, hence, is protected by the existing order entry's management of these data. If the new application fails, no data are lost. In the worst-case scenario, an order does not make it to the sales application and would have to be re-entered by the end user. StoreCompany data sharingStore inventory and client accounts data are located in the z/OS DB2 and are shared across the sysplex. Linux accesses (shares) these data only through interaction with applications that run on the sysplex, using connectors to CICS and DB2. StoreCompany backup and restoreBecause the new Linux images own no business data, the impact on the existing StoreCompany backup and restore processes is minimal. The 3390 disks with Linux system data and the new application are backed up at the file level as part of the scheduled weekly Linux backup. As the need arises, important intermittent changes to configuration files or the application are handled by the Linux development team and are backed up with the help of the tar and ftp commands to a remote system. The new application requests a data extract from the corporate data warehouse once a week. The query is performed by the database manager on z/OS. The extract is written to a separate tablespace on z/OS and is then sent to the Linux image by ftp. If the data get lost or damaged on the Linux side, it can easily be restored from the original on z/OS. StoreCompany disaster recoveryStoreCompany covers its disaster recovery needs by maintaining a similar infrastructure at both its two major sites, including similar sysplexes and storage devices. The Linux project is not part of the immediate disaster recovery plan, but could be recreated from the backups that are compressed with tar and then transmitted to a remote system with ftp. |
EAN: 2147483647
Pages: 199