Platform Operations Concept for zSeries with z/VM

Art Olbert Linuxcare, Inc [email protected] 415-354-4346

LINUXCARE PAGE 1 OPERATIONS CONCEPT

OperationsOperations ConceptConcept definesdefines thethe process,process, roles,roles, andand approachapproach toto effectivelyeffectively useuse andand supporsupportt LinuxLinux onon thethe z/VMz/VM platformplatform

4Capabilities and key concepts of the Linux on z/VM platform • Building blocks of the z/VM platform? • Capabilities of the platform? • Key concepts? 4User roles • Who uses the platform and why? • Who is responsible for what? 4Operations scenarios • How is the platform operated?

LINUXCARE PAGE 2 OPERATIONS CONCEPT

OperationsOperations ConceptConcept definesdefines thethe process,process, roles,roles, andand approachapproach toto effectivelyeffectively useuse andand supportsupport thethe LinuxLinux onon z/VMz/VM platformplatform

4Capabilities and key concepts of the Linux on z/VM platform • Building blocks of the z/VM platform? • Capabilities of the platform? • Key concepts? 4User roles • Who uses the platform and why? • Who is responsible for what? 4Operations scenarios • How is the platform operated?

LINUXCARE PAGE 3 BUILDING BLOCKS OF LINUX ON z/VM PLATFORM

The platform consists of: IBM z/VM to virtualize servers running standard Linux OS and software stacks, and

Levanta to provision and E-mail J2EE Database DNS/ Firewall Lines of administer these virtual DHCP LOB1 LOB2 LOB3 LOB5 business (LOB) servers LOB4 applications (decentralized)

DNS/ E-mail J2EE Database Firewall Levanta DHCP Linux Linux Linux Linux Linux

Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual machine machine machine machine machine machine machine machine

IBM z/VM operating system Linux on z/VM platform IBM zSeries mainframe (mainframe)

LINUXCARE PAGE 4 WHY USE THE PLATFORM

Typical software Platform capabilities Example value applications used

• Provide developers with own Linux servers • Linux development Provide a state-of- on demand • Java development the-art development, test, and production • Smoothly migrate software: development - environment test - production • Run any Linux application (without modification) • Follow mainframe standards regarding reliability and disaster recovery • Retain flexibility of decentralized Linux systems • Provide virtual Linux servers instead of • Domain name server Consolidate distributed servers for use in infrastructure (DNS) distributed servers applications • Firewall • Optimize Linux applications by leveraging • File/Print mainframe capabilities • Web serving • Generate a new virtual server (instance) in • Java/J2EE minutes • E-Mail • Allow for efficient administration of virtual servers through management software Web-enhance • Bring mainframe business logic and data to • Apache web server mainframe business the Internet by using Linux z/VM and • Java/J2EE processes Hipersocket fast networking • Database connectors

LINUXCARE PAGE 5 NECESSITIES FOR EFFECTIVE DEPLOYMENT OF LINUX ON z/VM PLATFORM Platform component High-level description Benefit

BestBest practicepractice • Description of components • Easy creation and modification of server configs serverserver that define a virtual server • Re-use server configs in multiple virtual servers configsconfigs (e.g., hdw, op sys, appls) • Create (harvest) of new server configs from running virtual servers • Instantiation of virtual • Efficiently creat new virtual servers (in minutes) VirtualVirtual serverserver server config, in a virtual • Group of virtual servers for easier management machine and administration

• Sufficient data to reconstruct • Capture of installation / config changes BackupBackup andand a virtual server, and a method • Ability to restore a virtual server to consistent state RestoreRestore to do so • Propagate specific change(s) to group of virtual servers • Location to store common, • Access / share mainframe resources among SharedShared best practice server configs, virtual servers (e.g., DASD storage, processors) storagestorage binaries, and user content • Storage of arbitrary data (e.g., server configs, software components, any user file) • Simple/efficient backup & disaster recovery (DR) • Isolated / encapsulated • Easily partition mainframe into virtual machines VirtualVirtual portion of the mainframe, to • Flexible & efficient mgm’t of virtual machines machinemachine run virtual servers • Strong isolation between virtual machines

• Physical hardware platform, • Reliable / efficient operation of mainframe MainframeMainframe and core hypervisor to hardware and hypervisor (z/VM) operate the hardware • Hardware and software support of efficient “virtualization” LINUXCARE PAGE 6 “BEST PRACTICE SERVER CONFIGURATIONS” DESCRIBE THE COMPONENTS OF VIRTUAL SERVERS

Virtual server #1 Virtual server #2 (“Web server”) (“Firewall”)

“Application” “Application” Platform capabilities

• Easy creation and modification of server configurations • Re-use of server “Linux “Linux configurations Platform” Platform” • Creation of new server configurations from running virtual servers

Server configuration • Virtual machine • Linux OS • Applications Kernel Kernel

LINUXCARE PAGE 7 “VIRTUAL SERVERS” CAN BE CREATED FROM SERVER CONFIGURATIONS AND MANAGED IN LARGE NUMBERS

Creation, deployment, and cloning

Virtual Complete servers and server server configurations groups Shared DASD Backup Role-Based Permissions Role-Based Shared DASD Role-Based Permissions Role-Based Web UI

“Harvested” IndividualIndividual oror server groupgroup changechange ConfigurationConfiguration changes configuration managementmanagement changes Linux interface data

• Update Platform capabilities • Change configuration • Efficient creation of new virtual servers • Roll back (in minutes) Mainframe interface • Roll forward • Grouping of virtual servers into “virtual server groups” for easier management

LINUXCARE PAGE 8 TAILORED LINUX “VIRTUAL SERVERS” ARE CREATED WITH LEVANTA PROVISIONING / ADMIN TOOL

Application Application Application Standard Levanta Linux distribution Install Linux Configure Linux Boot Linux platform platform platform

Unconfigured Configured Linux Running Linux virtual virtual server Linux virtual server server Virtual machine Server Edit configurations server and changes configu- • Virtual machine rations • Linux OS • Applications

LINUXCARE PAGE 9 INSTALLATION AND CONFIGURATION CHANGES ARE RECORDED AND “ROLL-BACK” IS ENABLED

Install Configure Boot Application

Linux platform

Unconfigured Linux Configured Linux Running Linux virtual server virtual server virtual server

Installation and Reconfigure configuration changes

Package selection Capture changes Configuration Platform capabilities

• Capture of installation and configuration changes • Ability to always restore a virtual server to a consistent state • Propagation of a specific change to any group of virtual servers

LINUXCARE PAGE 10 COMMON BINARIES ARE AUTOMATICALLY PLACED IN “SHARED STORAGE” TO SAVE SPACE AND IMPROVE MGMT

Virtual servers

Apache Java/ DNS/ E-Mail web J2EE DHCP server • Reduces virtual Levanta server creation time Linux Linux Linux Linux • Simplifies backup and disaster Virtual Virtual Virtual Virtual Virtual Virtual recovery machine machine machine machine machine machine • Simplifies considerations for mirroring and IBM z/VM clustering • Saves disk space Shared storage (DASD) Unique storage (DASD) • Leverages mainframe Read-only resources Read-only Instance specific shared Linux Instance specific shared Linux binaries binaries binaries binaries (backup) (backup)

LINUXCARE PAGE 11 Overlays and automatic shared DASD

Shared repositories Virtual DASD content

Applications A B Overlay C D

OS A Base content B

• When a virtual server is created by Levanta, all its files and directories are obtained from repositories • All disks containing Levanta repositories are shared read-only by all virtual servers • Files that are modified on a virtual server are copied to a special partition called an overlay; added and deleted files are also handled using the overlay

Benefits of overlays

• All disks containing Levanta repositories are shared read-only by all virtual servers • Files that are modified on a virtual server are copied to a special partition called an overlay; added and deleted files are also handled using the overlay • Only changes are stored on DASD uniquely

LINUXCARE PAGE 12 OPERATIONS CONCEPT

OperationsOperations ConceptConcept definesdefines thethe process,process, roles,roles, andand approachapproach toto effectivelyeffectively useuse andand supportsupport thethe LinuxLinux onon z/VMz/VM platformplatform

4Capabilities and key concepts of the Linux on z/VM platform • Building blocks of the z/VM platform? • Capabilities of the platform? • Key concepts? 4User roles • Who uses the platform and why? • Who is responsible for what? 4Operations scenarios • How is the platform operated?

LINUXCARE PAGE 13 USERS OF PLATFORM BY ORGANIZATIONAL UNIT

Support Organizational Development System test unit Production Network

Sample • Provision / reconfigure • Requires perfect copies • Quick migration and requirements dozens of experimental of production deployment of new servers servers environment for testing from test to production • Develop specialized and• Create fine-tuned • Capacity planning asks for optimized software variations of production more servers in response to versions for various servers, with differing growing system load virtual servers configs workload & user profile • Deploy virtual servers Typical tasks • Create virtual server – Install multiple images performed – Provision virtual machine (e.g., – Deploy image updates memory, DASD storage, CPU) – Capture changes – Install OS and application • Manage virtual servers – Change server configs – Roll back / forward changes – Cycle/upgrade the OS – Backup and restore servers – Re-configure virtual machines – Grow / shrink server numbers • Develop and test applications – Define standards, security – Modify configs to debug guidelines and service level – Track changes to configurations agreements (SLAs) – Tune configurations • Support users – Configure network – Capture/resolve problems – Train users LINUXCARE PAGE 14 DIFFERENT TEAMS COLLABORATE ON THE PLATFORM Mainframe teams work with distributed teams Distributed teams Network Application developer Database Mainframe teams administrator group (e.g., J2EE) team

Samba Websphere DB2 connect

“Good“Good FencesFences Linux Linux Linux Unix/Linux system MakeMake GoodGood administrator Neighbors” Neighbors” IBM z/VM

IBM zSeries z/VM system administrator

Linux zSeries with Levanta fosters collaboration among different teams • Effect self-service model through roles, enforced by access permissions – Enable defined interaction with system and provide protection – Logs capture changes and allow for rollback • Reduce cultural barriers by providing multiple, familiar interfaces

LINUXCARE PAGE 15 ROLES ON PLATFORM (1/2) Support Development System test Production

Network Platform Roles Played by Whom

Server Monitor • Server operator (“monitor / restart virtual servers”) • Basic support of users Server User • Application developer • QA test engineer, e.g. • Server admin - basic ops (“own / use – Web applications virtual servers”) unit tests, dependency • Data base admin – Linux applications checks • Linux server mgr/admin Server Manager • Linux server mgr/admin • Server mgr - advanced operations (“create / manage for unit test team for a development team e.g. restore virtual server (DR) virtual servers”) •Sys level QA/test engineer, • Sys prog with ability to • Database mgr (advanced) able to create / modify create modify servers • Advance/expert user support servers Software Mgr (“approve / publish • Appl development / • Sys test / final release • Mainframe res mgr (e.g allocate virtual server”) certification mgr manager DASD, plan consolidation Resource Mgr (“provision / • Mainframe operator allocate mainframe • Add / config hdw resources”) System Mgr • Head of platform (“operate mainframe”) • Oversee operations Supervisor (“manage platform”)

LINUXCARE PAGE 16 ROLES ON PLATFORM (2/2) Platform role… …Key activities and capabilities… …Played by Whom

• Monitor and operate virtual servers • Virtual server operator (monitoring) ServerServer “Monitor and MonitorMonitor restart virtual • Restart virtual servers if needed • First-level support (FLS), e.g., servers” (e.g., upon failure) – Basic support of a user group • Start and stop virtual servers • End user (e.g., application developer, “Own and use • Perform routine operations (e.g., QA/test engineer, production operator) ServerServer UserUser virtual servers” daily backup of virtual servers) • Virtual server administrator (day-to-day) • Use virtual servers (“produce”) • Database administrator (day-to-day) • Procure, create and administer virtual • Virtual Linux server manager/admin “Create and ServerServer servers (through self-service) • System-level programmer ManagerManager manage virtual • Perform advanced virtual server • System-level QA/test engineer servers” operations (e.g., disaster recovery) • Database manager (advanced) • Provide advanced/expert support • Second-level support (SLS) • Develop new applications and define • Application development, configuration “Approve and SoftwareSoftware valid server configurations and certification manager publish virtual ManagerManager • Approve software configurations for • System test manager (for application server software” system testing and production release to production)

“Provision and • Manage virtual mainframe resources, e.g., • Mainframe resource manager ResourceResource allocate – Provision and allocate resources (for • Project manager for server Manager Manager mainframe later self-service by server managers) consolidation resources” – Manage mainframe resource pool • Perform basic mainframe operations • Mainframe operator (day-to-day) SystemSystem “Operate the (non-virtual machine view), e.g., – Mainframe and VM installation ManagerManager mainframe” – Install mainframe/VM environment – New hardware addition – Add and configure new hardware and configuration • Oversee Linux on z/VM operations • Head of data center “Manage the SupervisorSupervisor • Provide overall direction and guidance • Manager of technical services platform” LINUXCARE PAGE 17 LINKAGE BETWEEN ROLES AND IS / IT DEPARTMENTS

• Set and enforce • Set and enforce • Approve and publish virtual security policies network policies server software

Infrastructure or Policy Manager Policy Manager SoftwareSoftware Applications Group (Security) (Network) ManagerManager

SupervisorSupervisor • Manage the platform

Data Center ResourceResource SystemSystem ManagerManager ManagerManager • Provision and allocate • Operate the mainframe resources mainframe

Business Unit (BU) ServerServer ServerServer ServerServer UserUser ManagerManager MonitorMonitor

• Create and manage • Own and use • Monitor and restart virtual virtual servers virtual servers servers

LINUXCARE PAGE 18 Note: Several roles may be held by the same individual OPERATIONS CONCEPT

OperationsOperations ConceptConcept definesdefines thethe process,process, roles,roles, andand approachapproach toto effectivelyeffectively useuse andand supportsupport thethe LinuxLinux onon z/VMz/VM platformplatform

4Capabilities and key concepts of the Linux on z/VM platform • Building blocks of the z/VM platform? • Capabilities of the platform? • Key concepts? 4User roles • Who uses the platform and why? • Who is responsible for what? 4Operations scenarios • How is the platform operated?

LINUXCARE PAGE 19 OPERATIONS SCENARIOS

Scenario Key activities Involved parties Platform roles

• Develop software applications • Application developer •Server User Software Software • Define and approve valid software • Application certifier • Software Manager DevelopmentDevelopment configurations • Test software, using defined test • Quality assurance (QA)/ •Server User SystemSystem TestingTesting scenarios and procedures test engineer • Server Manager • Define/publish test guidelines (if needed)

• Ensure rapid rollout/upgrade/staging • QA/test engineer •Server User SoftwareSoftware DeploymentDeployment of OS and applications (on a large • Production team • Server Manager number of virtual servers) (if needed)

• Ensure smooth transition from • Application developer •Server User Software Change Software Change development to test to production • QA/test engineer • Server Manager ManagementManagement • Production team (if needed)

• Perform regular backup of virtual • Virtual server admin •Server User Backup/Restore and Backup/Restore and servers for recovery purposes • Virtual server manager • Server Manager DisasterDisaster RecoveryRecovery • Restore virtual server if needed • Database manager

• Provision new mainframe resources, • Mainframe resource • Platform Manager Resource and Resource and in response to growing system load manager • Resource Manager CapacityCapacity ManagementManagement • Re-distribute load to newly created • Virtual Linux server • Server Manager virtual servers managers/administrators

• Report and escalate user problems • End user •Server User ProblemProblem ManagementManagement • Analyze and resolve problems • Support and help desk • Server Monitor • Development (if needed) • Server Manager

• Re-create a group of physical • Head of data center • Resource Manager ServerServer ConsolidationConsolidation servers on the mainframe • Resource manager • System Manager • Virtual server manager • Server Manager LINUXCARE PAGE 20 SAMPLE SCENARIO SOFTWARE DEVELOPMENT Scenario: Rapid provisioning of virtual servers for development (e.g., 10 different configs) Application teams J2EE team Procure new virtual (development) server Hand Web server team Procure new virtual over to • Web server • Web server (development) server •• DBDB serverserver system •• …… testing DNS/DHCP team Modified Server Procure new virtual virtual server configurations (development) server

ment Best practice approach n develop Applicatio guidelines reation Package c ______• Application developer teams request a new ______virtual test server for development purposes ______Required • Software development is guided by standard ation document ______application development guidelines, e.g., ______– Rules for creation of RPM packages (name ______edures Test proc conventions, installation/configuration scripts) ______– Required documentation (e.g., manual pages, ______user guide, operations manual) __ – Test procedures and scenarios • Well-defined interface to system testing is in place (e.g., documented test procedures)

LINUXCARE PAGE 21 SAMPLE SCENARIO SYSTEM TESTING Scenario: Testing and certification of a procured (or self-developed) software application

Yes NeedsNeeds moremore develop-develop- No ment?ment? No

From Yes To Test OK?OK? Fine tune OK?OK? development Yes Production

Virtual server Tested and AA to be tested Test standards Workload fine-tuned BB ______requirements virtual server CC ______Server configuration ______W-1.0W-1.0 Dependency AA information CC Specific test BB scenarios Flexible metadata ______Modified Repository ______(optional) ______server ______configuration

Best practice • Obtain virtual server to be • Test the virtual server using • “Fine tune” the • Capture changes to the approach tested from application standard test guidelines virtual server, e.g., fine-tuned virtual server by development group • Run virtual server through the –System harvesting (i.e. creating) a • Ensure documentation is specific test scenarios provided parameters new server configuration complete (e.g., manual, • (Optionally) augment dependency – Workload • Hand over tested and fine- test scenarios) information stored in server profile tuned virtual server (and configuration through “flexible server configuration) to metadata” production

Platform support • Instances (virtual servers) • Instances • Templates • Harvesting an instance • Templates (server • Flexible metadata (containing • Change • Repository (data storage) configurations) dependency information) management LINUXCARE PAGE 22 SAMPLE SCENARIO SOFTWARE CHANGE MANAGEMENT Scenario: Upgrade of all existing production web servers to a new version of Apache

Organization unit Development System test Production

Other virtual production Develop new servers software version W-1.0W-1.0 Yes Other NeedsNeeds W-1.0W-1.0 further Roll out further W-1.0W-1.0 virtual develop-develop- change to W-1.0W-1.0 tch No production Pa ment?ment? production W-1.0W-1.0 W-1.0W-1.0 servers No servers W-1.0W-1.0 W-1.1W-1.1 Final Test and Final Apply change OK? W-1.1W-1.1 W-1.0W-1.0 W-1.1W-1.1 fine tune OK? Yes FinalFinal Create new W-1.0 server W-1.0 Unmodified virtual Modified Test standards Tested and W-1.1W-1.1 ______config from (test) server virtual server fine tuned FinalFinal ______modified ______virtual server Server server configurations Server configurations Best practice • New software version (e.g., • Test modified server, with • Roll out (apply) a tested change to approach patch, upgrade) standard test guidelines production servers • Create new test server from • “Fine tune” the server • Harvest / export a new server existing server config • Hand over tested tuned config from a changed server (for • Apply change/patch to that server to production creation of future servers server only • If needed, roll back a change Platform support • Templates (server configs) • Instances contain • Instance groups & • Instances (virtual servers) compatibility / harvesting • Change log • Templates dependency information PAGE 23 LINUXCARE • Repository (data storage) SAMPLE SCENARIO VIRTUAL SERVER BACKUP AND RESTORE Virtual server to Scenario: Weekly backup of all virtual production web servers be backed up Linux on z/VM platform Linux on z/VM platform Virtual servers Virtual servers

DNS Print Apache E-mail DNS Print Apache E-mail “Checkpoint”

Linux Linux Linux Linux Linux Linux Linux Linux

Levanta Levanta

z/VM z/VM

Shared storage (DASD) “Rollback” Shared storage (DASD) Apache

Read-only Read-only data data Linux

Backup Restore • Regularly back up servers by “check- “Checkpoint” Best AA BB • If needed, reconstruct a virtual pointing” practice server by “restoring” it from the • Virtual server • Archive backup copies for recovery configuration check-pointed image approach purposes • Virtual server data • All file system data • State-based view captures all installation and configuration changes) (state-based view) Platform • Shared repository (speed up backup/restore procedure) • User content support • Access to mainframe resources (e.g., DASD storage) Sufficient information to • Checkpoint and rollback (backup and restore) reconstruct virtual server • Instances (virtual servers) • Templates (server configurations) LINUXCARE PAGE 24 SAMPLE SCENARIO VIRTUAL SERVER DISASTER RECOVERY Scenario: Restore production web servers to a well-defined state after loss

Failed virtual server Linux on z/VM platform (e.g., after crash) Virtual servers

DNS Print Apache E-mail • “Free” disaster recovery from: – State-based view – backup copy Linux Linux Linux Linux contains full state of a server, including all changes made, and Levanta – Rollback – possibie return a server “Restore” to any prior check-pointed state z/VM • Fast execution of DR enabled by Shared storage (DASD) – One centralized data storage (repository) that accessed by all Apache Apache Read-only Linux servers Linux data Linux – Optimal use of mainframe resources (e.g., DASD storage) “Check-pointed” servers – Predictable, reliable, and space- efficient rollback operation Best practice • Perform regular backups of running virtual servers (e.g., daily/weekly) approach • Back up most critical virtual servers more frequently (e.g., daily/hourly) • In case of a lost virtual server, restore its state from previously generated backup copy Platform • Instances (virtual servers) support • Checkpoint and rollback (backup and restore) • Shared repository (shared storage)

LINUXCARE PAGE 25 DISASTER RECOVERY ACTIVITIES BY ROLE

Platform role Played by Whom Activities

•Server • Linux systems administrator • Perform routine backups of User (day-to-day operations) individual virtual servers • Database administrator (e.g., daily checkpoint)

•Server • Linux systems manager (with • Perform backup of the entire Linux Manager advanced privileges) on z/VM platform • Database manager • Restore some or all virtual servers to a previously saved state (rollback)

• System • Mainframe system administrator • Escalate to management in case of Manager major problem (based on defined disaster scenarios)

LINUXCARE PAGE 26 SAMPLE SCENARIO RESOURCE AND CAPACITY MANAGEMENT Scenario: Dynamically create new virtual production web servers, in response to growing system load

Linux on z/VM platform Linux on z/VM platform

Virtual production servers More virtual production servers Apache Apache Apache Apache Apache Apache Apache Apache Apache Apache Apache Apache LinuxApache LinuxApache LinuxApache Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux

Levanta Growing Levanta system load z/VM z/VM

Shared storage (DASD) Shared storage (DASD)

Data Data (backup) (backup) Data Data New DASD storage (optional)

Best practice • Provision enough virtual servers to meet • Ask for more virtual • Provision mainframe resources dynamically, approach estimated initial system load requirements servers, in response to e.g., DASD packs (do not need to shut down • Monitor system load on an ongoing basis growing system load the platform when adding new resources), • Redistribute total system processing capabilities load to newly procured virtual servers

Platform support • Instances (virtual servers) • Instance (creation) • Templates (server configurations), • Instance groups used to abstract various hardware components (through “template levels”) LINUXCARE PAGE 27 CAPACITY MANAGEMENT ACTIVITIES BY ROLE

Platform role Played by Whom Activities

• System • Mainframe system • Maintain and configure mainframe/VM Manager administrator resources (e.g., add DASD storage)

• Resource • Mainframe resource • Configure mainframe/VM resources for Manager manager subsequent allocation/delegation • Provision and allocate mainframe resources for later self-service by Server Managers, based on their request (e.g., provide additional 10GB of disk space) • If all mainframe/VM resources are allocated, procure new mainframe/VM resources (subject to budget approval) • Define policies and guidelines for mainframe/VM resource usage

•Server • Linux system manager • Procure, create and administer virtual Manager (with advanced privileges) servers, using the mainframe resource pool previously allocated by the Policy • Database manager Manager (i.e. through self-service) (with advanced privileges) • If allocated resource pool is used up, request additional virtual servers/ resources from Resource Manager

LINUXCARE PAGE 28 SAMPLE SCENARIO PROBLEM MANAGEMENT Scenario: User reports a problem with a virtual production server

First level support Second level support End user Development and Test (FLS) (SLS)

Create a “copy” Help Trouble Try to solve of the virtual desk ticket problem server Copy of Copy of virtual server virtual server Try to solve May make problem changes to Fix problem (e.g., virtual server code change, bug fix)

CanCan Pass on to CanCan Pass on to solve?solve? No SLS solve?solve? No Developer Virtual production Corrected server server

Yes Yes Create new virtual server Report to development Corrected sv configuration Best • End user reports a problem • Isolated copy of erroneous • SLS (e.g., expert team) tries • Development team fixes the practice with virtual production server virtual server is generated to solve the problem problem (e.g., code change) approach (via helpdesk) to FLS (e.g., (from running virtual server) • SLS may have authority to • The fix is captured by system administrator) • FLS (e.g., system admin) make changes to the virtual – creating a new version of the • User describes the problem, tries to solve the problem server configuration virtual server (e.g., a patch) specifies and “passes on” • FLS escalates the problem • If needed, SLS “passes on” – harvesting a new server virtual server to FLS to SLS if necessary the problem (and the virtual configuration (for future • Trouble ticket is generated server) to development creation of virtual servers) Platform • Instance (virtual server) • Harvesting of an instance • Instance (being “passed on”) • Instance creation/update support (e.g., capture state of the • Templates (server configurations) virtual server just before and after the failure) LINUXCARE PAGE 29 SAMPLE SCENARIO COMBINATION OF DISTRIBUTED SERVERS Scenario: Combine physical web servers into virtual servers on the z/VM platform “Before” – Distributed systems “After” – Linux on z/VM platform Virtual servers

Develop- Pre- Other Test Production ment Production

Virtual Virtual Virtual App server Virtual machine machine machine machine

DB server Server Levanta integration Develop- Test Pre- Production z/VM ment Production Shared storage •Isolation (DASD) • Distributed servers (18 physical machines) • Encapsulation Data (backup) • Complex provisioning, staging, deployment, Data backup, and disaster recovery (DR) • Expensive to maintain and operate

• Simplified administration • More robust backup and DR • Cost-effective operations

Best practice • Ensure there mainframe resources available (to combine servers) approach • Capture config of the real/distributed servers by creating server configs • Create virtual servers on z/VM platform, using the captured server configs Platform support • Templates (server configurations) • Instances (virtual servers) LINUXCARE PAGE 30 SERVER COMBINATION ACTIVITIES BY ROLE

Platform role Played by Whom Activities

• Supervisor• Manager of data center • Approve and oversee server combined operations project

• System • Mainframe system • Configure mainframe/VM resources, to Manager administrator meet expected additional work load requirements

• Resource • Mainframe resource • Allocate mainframe/VM resources, to hold Manager manager servers to be consolidated

•Server • Linux system manager • Create new virtual server configurations Manager • (with advanced privileges) that match the previously distributed • Database manager servers • Create virtual servers to replace the distributed servers (consolidation)

LINUXCARE PAGE 31 Banking Case Study

“Streamlining • International multibank HQ’d in the midwest ~$35 B assets maintenance and SITUATIONSITUATION • Accessed mainframe CICS / DB2 data via of gateway servers administration of a • Desired improvements growing Linux – Reduce complexity and points of failure environment – Reduce the number of servers managed requires a – Error resolution too complex, touched too many parties software-based – Shorten time for disaster recovery solution. We were – Increase system reliability and system supportability impressed with its – Reduce time on emergencies; address new business ability to bridge the technology • Moved to DB2 Connect servers to mainframe BUSINESSBUSINESS • Reduced disaster recovery time differences SOLUTIONSOLUTION between the • Increase scalability mainframe and • Reduce support overhead distributed system • Trouble ticket resolution simplified (Mtgs 3x / week to none) support • Retired numerous servers environment, • IT now focused on revenue generating endeavors allowing our • New virtual server instances; change mgmt of multiple traditional LEVANTALEVANTA instances; maintain patches and updates mainframe system VALUEVALUE • Easier Linux release upgrades; rapid new Linux instance create programmers to • Access to features and function of z/VM without a steep learning now maintain and curve - able to share DASD and allocate network IP addresses administer Linux. • Bank has successfully migrated all to DB2 As Linux use ITIT proliferates in our SOLUTIONSOLUTION Connect related on z900, using zLinux, organization, we'll Levanta, and SuSe be ready." LINUXCARE PAGE 32 Platform Operations Concept for zSeries Linux with z/VM

Art Olbert Linuxcare, Inc [email protected] 415-354-4346

LINUXCARE PAGE 33