IT Continuity. Assured.

Transcription

1 IT Continuity. Assured. architect verb [ with obj. ] Computing design and configure (a program or system) Introduction This technical white paper is designed to help IT Infrastructure & Operations (I&O) professionals understand what problems Neverfail (Architect) solves, how the product works and what value they can expect from deploying it within their datacenter. Let s start with a discussion of the problems and issues that Architect seeks to address. The Disconnect between Disaster Recovery Readiness & Business Requirements With virtualization now ubiquitous in the modern datacenter, IT infrastructure is now more agile than ever. It has to be agile in order to deliver competitive advantage yet live within the reality of shrinking IT budgets. Moreover, businesses are increasingly dependent on reliable IT systems and demand stringent service levels. While virtualization has made it easier to protect individual virtual machines (VMs), ironically, it s harder than ever to assure that protection will work as intended across complex business services. IT Infrastructure and Operations (I&O) professionals face three fundamental challenges: The hidden cost of virtualization. With virtual infrastructure, workloads can be deployed or relocated faster than ever. Yet how many I&O professionals have an accurate, up-to-date and easy-to-interpret blueprint of what applications live where, who uses them, and what dependencies (known and unknown) exist with other applications, VMs and hosts? Does agility come at a price if it unravels protection strategies without prior warning? IT lacks clear visibility into how the IT infrastructure maps to business services and whether availability service level targets can be met. Change is the new normal. In the modern datacenter, the infrastructure is changing constantly. New VMs may put additional load on the infrastructure, or configuration changes may impact components that are vital to a business service. Ask yourself a simple question: without a current blueprint of your IT assets and their inter-dependencies, can the full impact of a change be understood? What appears to be a relatively unimportant change to the infrastructure might turn out to be critical to your Tier1 applications. And when that component fails, are you in for an unpleasant surprise? 1

2 Knowing whether business continuity and disaster recovery plans will work. Companies increasingly rely on IT, so business operations can come to a halt in an outage but it turns out this is complicated. Business services are composed of distributed application components running on multiple platforms virtual, physical, different operating systems or hypervisors that in turn depend on multiple protection technologies. How will the recovery of an entire business service within service level targets be planned for and then assured over time, given heterogeneous protection infrastructure and constant change? The end result: A gap exists between IT s business continuity readiness and the organization s expectations for service availability. IT sees disaster recovery and business continuity in terms of the infrastructure that they manage, patch, backup and protect, but lack insight into how the infrastructure ties to business services. The business just expects IT to figure out how to keep it running. As a result IT takes the brunt of the blame for any outage with little support for implementing proper strategies and solutions to protect the business from downtime. IT infrastructure and IT continuity need to be managed from the perspective that really matters: that of the consumers of the business services the end-customer, whether internal or external to the organization. Read on, and we ll explain how Architect brings a fresh perspective to addressing these challenges using a game-changing IT continuity management approach. Neverfail Overview Architect bridges the gap between IT infrastructure and business services so you can trust that your business continuity plans will always work. Architect automatically discovers and analyzes IT infrastructure, maps dependencies across various layers of the infrastructure including applications and business services and tracks changes, showing you what is at risk and what you need to do to assure continuity. By letting IT set Recovery Time and Recovery Point Objectives (RTO and RPO) by application as well as business services, Architect allows companies to decrease the risk of outages, reduce the cost of disaster recovery infrastructure and maintain compliance with service level commitments. Simply put, downtime puts your business and its reputation at risk; Architect helps you avoid downtime as efficiently and effectively as possible, even in the largest and most dynamic of environments. Architect works through a simple and streamlined process, beginning with deployment: 1. Packaging and Deployment. Architect is packaged as a Linux-based Open Virtual Appliance (OVA) that upon deployment registers itself as a VMware vcenter Server extension. It can be downloaded from the Neverfail web site and installed in less than 10 minutes. It comes with a built-in 30-day trial license that allows new users access to full product functionality. 2. Administration. Management of Architect is delivered as a user-interface plug-in to the VMware vsphere 5.1 Web Client (see Figure 1 Architect Dashboard). As such, the end-user experience should be very familiar to any VMware vsphere administrator. Figure 1: Architect Dashboard 2

3 The key features and associated benefits of Architect include: 1. Automated Infrastructure and Dependency Discovery. Once installed, Architect begins its discovery process that involves automated and agentless discovery of IT inventory and associated dependencies. Architect also renders these discovered dependency relationships in visual dependency graphs and heat maps that allows for intuitive and interactive comprehension. It can save you hours of manual effort by automatically identifying IT infrastructure, applications and their dependency relationships. 2. Business Services Mapping. Architect allows you to define business services based on underlying IT infrastructure dependencies and the resultant footprint. Consequently, Architect helps you understand which IT components are the most important to the business, and how business services map to IT infrastructure. 3. Define Business Continuity Targets. With Architect you can define business continuity and availability service level targets for each business service and immediately identify non-compliant components of the infrastructure. Architect provides four service level tiers that you can customize to define your own targets, then assign each business service to the appropriate tier. Architect automatically reports on any gaps or misconfigurations of protection infrastructure. This lets you know in advance if there are any gaps in your organization s protection strategy that put the business at risk. 4. Risk Identification Heat Maps. Architect includes visual heat maps that highlight the most critical risks in your infrastructure and helps prioritize remediation efforts. From the analysis of established availability service level tiers and the number of key dependencies, Architect s heat maps show which servers are the most critical to business continuity. The visual map lets you intelligently prioritize remediation efforts for systems that are out of compliance. Intuitive representation of infrastructure identifies the most critical IT components so you ll know what gaps to fix first. 5. Availability Monitoring and Reporting. Architect provides continuous monitoring, assurance and reporting of availability service level compliance. By automating the discovery of new or updated IT infrastructure, Architect dynamically ties changes to the impact on service level targets. This lets you proactively manage and report on business continuity preparedness and compliance. Architect provides you with assurance that the organization can meet business continuity commitments and keep the business online. Neverfail in Detail The following sections provide more detail on the concepts and technologies that Architect employs to discover, analyze, monitor and model production IT inventory to deliver value to its users. Packaging & Deployment One of the design goals for Architect was that it should be incredibly easy and quick to deploy while offering users fast time-to-value. Therefore it is packaged as a Linux-based Open Virtual Appliance (OVA) for rapid deployment, with a Flex-based management user interface plug-in that snaps into the VMware vsphere Web Client. Once downloaded from the Neverfail web site, Architect should deploy into your environment in less than 10 minutes. The Architect OVA is configured to deploy with a default of 4 vcpus and 4 GB RAM. The following prerequisites must be met in order to successfully deploy Architect: 1. VMware vsphere 5.x hypervisor as the target for deploying the Architect OVA 2. VMware vcenter Server 5.1 (or newer version) is required with which to register Architect as a vcenter Server extension and deploy the vsphere Web Client plug-in. 3. VMware vsphere Web Client 5.1 (or newer version) is required for accessing the Architect management interface that is available as a vsphere Web Client plug-in. 4. A minimum of 60 GB of available disk space on the datastore associated with the target vsphere hypervisor to accommodate the Architect appliance and the data that it generates. 3

4 5. 4GB of RAM (the Architect appliance deploys with 4 GB of RAM by default) 6. An available static IP address (assigned to the Architect appliance at deploy time) 7. Promiscuous mode must be enabled on the virtual network that the Architect appliance is configured with, in order to allow for proper discovery. The deployment process involves an OVF/OVA import that should be very familiar for vsphere administrators. During deployment, Architect asks for minimal configuration information about the user s IT environment in the form of vcenter Server name or IP to register with and associated administrator credentials. The selection of host network that the Architect appliance is configured with during the OVF/OVA deployment is crucial since it determines the initial scope and network boundary for Architect to perform discovery until some level of further analysis has been completed. Immediately upon deployment, Architect begins to discover entities within its host network and starts to perform an initial assessment using the vcenter Server credentials provided. Where to Deploy Architect Since the discovery phase of Architect sets the tone for ensuring accurate capture and quick analysis of an IT environment, the choice of deployment target in terms of the ESX host and vcenter Server instance to register with is an important decision point. The ESX host target is important to ensure the most optimal host network is available for initial discovery while the vcenter Server selection determines how expansive or restrictive is the discovery of vsphere inventory. If you choose to deploy and register Architect with a production vcenter Server running on a production network, Architect will be able to immediately discover and report on your most critical IT assets and their interdependencies. In this scenario Architect wouldn t need to perform network-based discovery for building the inventory of virtual infrastructure because it would obtain all necessary information via its integration with the VMware vsphere APIs. If you choose to pursue a more conservative deployment strategy of registering Architect with a test/development vcenter Server environment, the initial discovery process may be limited to non-critical inventory until Architect performs further analysis to discover other production networks and capture production inventory via the network-based discovery process. You can also help accelerate the discovery and analysis process by manually adding production networks and associated credentials for discovery and analysis. The choice is yours, and detail on how this is managed is provided in the next section. Discovery, Fingerprinting and Blueprinting Process Once installed and powered up, Architect will immediately get to work. Work proceeds based on three distinct phases that yield increasing amounts of information: initial Discovery; followed by Fingerprinting; and then Blueprinting (see figure 2 below). An overview of each phase follows: DISCOVERY FINGERPRINTING BLUEPRINTING Figure 2: Object Discovery 4

5 The initial Discovery phase uses active network scanning and passive packet sniffing to identify further networks beyond Architect s host network. Newly discovered networks are queued for Fingerprinting analysis but only when instructed to do so by the user. This phase also identifies IP addresses and ports of interest within given IP ranges for each network that is analyzed; The next discovery phase, known as Fingerprinting, profiles each IP address of interest to differentiate routers, switches, desktops, servers and hypervisors. Again, scope is restricted to just those networks that have been enabled for discovery. Fingerprinting enables Architect to discover more granular information such as server name and installed operating system. The final phase of discovery, known as Blueprinting, enables Architect to run scripts or exercise APIs on each server remotely. These scripts analyze all active connections between the profiled server and other entities on the network. Together with port analysis, this process underpins Architect s dependency analysis, which is key to enabling the Architect user to easily associate a set of collaborating IT objects with a defined business service. An important design decision was to minimize impact of Architect s activities on the environments it profiles. Discovery has been implemented as an agentless activity in order to minimize management overhead. Furthermore, discovery activity is throttled to minimize impact on the network. Throughout the discovery process, progress is displayed in a portlet (figure 4) within Architect s management console. Figure 3: Discovery progress reporting Blocked Entities Some entities may be blocked from further analysis pending provision of new security credentials. The heat map (Figure 4) in Architect helps users prioritize efforts to provide credentials for blocked servers the larger the rectangle, the more infrastructure that entity supports. Figure 4: Discovery Heat Map 5

6 In this particular context, each box on the heat map represents a blocked entity. Users can simply click on the largest boxes to drill down to a more detailed view, browse the alerts related to that entity to see the reason for the blockage and then take action based on the advisory note included. Required actions may be to add more credentials, add network routes or open ports on servers or firewalls. Discovered objects All information obtained during the discovery process is stored in Architect s database pending further analysis. Information of interest includes (but is not limited to): Networks Servers (both physical and virtual) Hypervisors Operating systems Protection technologies Specific supported applications Generic applications User devices Interdependencies between all of the above Credentials Management Architect secures communication of passwords between its vsphere Web (management) client plug-in and the Architect appliance using robust encryption. Furthermore all credentials (username, passwords, etc.) are stored in an encrypted format within the Architect database. As such, all sensitive information captured by Architect is secured. Event-driven model Architect s database is populated under user control as each discovered network is released for further profiling. In this way, the bulk of discovery takes place in the days following Architect s deployment. However, Architect has been designed around an event-driven model that allows its database to be updated in real-time as changes occur within your infrastructure. The key benefit of using an event-driven model is that it allows Architect s disaster recovery assurance functionality to alert users immediately to any change within the infrastructure that could compromise the availability of key services within service level targets. Architect Workflow All initial discovery activity takes place in the background following deployment. The user intervenes only to release discovered networks or provide credentials to specific systems for further profiling and blueprinting by Architect. However, once a significant portion of your IT inventory has been discovered, you can begin to exercise its analysis and service management tools to produce some quick wins. While Architect does not impose any specific workflow, Neverfail recommends the following process: Download, deploy, register Auto discover infrastructure and dependencies Explore and analyze results Create Business Services over infrastructure Assign protection policies to Business Services Explore protection assessments against policy Report on overall risk exposure? Model mitigations & solutions to risks Monitor for new risks against policy baselines and react Figure 5: Suggested Architect workflow 6

7 Explore and Analyze Results In the third activity shown in Figure 5, Architect offers some intuitive tools to explore and analyze the results of discovery. IT Architects and IT Managers will be interested in Architect s dependency graph that allows easy exploration of interdependencies. Questions such as which VMs use this SQL database, or which applications consume this web service are quickly answered. The dependency graph is shown below in Figure 6. Figure 6: Architect s dependency graph Architect also provides detailed information for each analyzed entity showing core attributes and protection status. In order to obtain a complete perspective of the IT infrastructure and assess overall protection status, it is highly recommended that users should define a set of business services (e.g. the service) as documented in the suggested workflow above in Fig. 5. Next, after associating the business service with the relevant dependent IT infrastructure, users can apply a protection tier to the entire service, inclusive of the business service just created and all of its dependencies, thereby obtaining an assessment on aggregate protection status. Business Services The concept of a business service within Architect is fundamental to extracting the IT Continuity Assurance value that the product delivers. A business service is an aggregation of IT components that ultimately supports a discrete function that both business and IT user will readily understand (e.g. payroll, order processing). Architect was designed around this concept because negotiating service level agreements at the level of individual IT components is too complex and therefore meaningless to users. For example, a user will certainly agree that they use and they will most likely demand Tier 1 protection status for such a critical service, but they are disinterested in the minutia of what IT services collaborate under the hood to deliver . By contrast, I&O professionals are very interested in making sure that all of these collaborating IT services that deliver are adequately protected so that is always available. Architect provides a view of each business service that shows its dependent IT components (Figure 8). 7

8 Figure 7: A view of the Finance business service in Architect Business services can be created and populated with dependent IT components very easily. Architect s dependency mapping makes it simple to create business services and link the relevant IT assets to them. There are two approaches to creating a business service within Architect: A top-down approach by identifying a specific application (e.g. a Microsoft SharePoint server) and then using Architect s dependency mapping features to automatically identify all the connected infrastructure components to load into e.g. the Document Management business service. A bottom-up approach by choosing the database server (or VM) for the relevant service (e.g. the Microsoft SQL database instance that s used for SharePoint), then following all dependencies up the infrastructure stack to load into the business service. In either case, all of the relevant infrastructure supporting the SharePoint instance is identified and classified as part of the Document Management business service. Protection Tiers Once a business service has been defined and populated with dependent IT assets, the next step is to sit down with a business user and negotiate an appropriate service level as defined by one of four Protection Tiers offered within Architect. Each protection tier comes with default settings that may be overridden to reflect custom settings most appropriate and relevant to a specific IT environment. These settings define scope of protection (i.e. data protection or backup, HA protection against application or server failures, DR protection against site failures) and performance of protection (i.e. availability targets, RTO, RPO), as shown in Figure 8. DR Assurance Once correctly configured, it is a single click exercise to assign the appropriate protection tier to any given business service. At this point, Architect performs analysis on each dependent IT component within the business service. It applies its knowledge of the deployed protection infrastructure for each component to determine whether or not it will meet the required service level agreement (as set out in the Protection Tier). 8

9 Figure 8: Protection Tier settings Let s take the example of an service in three possible scenarios: In the first scenario, the Protection Tier calls for protection to a disaster recovery site with a Recovery Point Objective of 120 minutes for the service (i.e. no more than 120 minutes worth of will be lost during a failover to the disaster recovery site). Architect sees that vsphere replication has been deployed on the Exchange Server VM and has been configured to replicate changed VM blocks every 60 minutes. In this instance, Architect would report a green status for the Exchange server. On the other hand, if the Protection Tier for calls for a Recovery Point Objective of 30 minutes, Architect would report an amber status for Exchange. This means that would not meet its service level target of 30 minutes hour because replication takes place every 60 minutes. But Architect knows that vsphere replication could be configured to meet the given target and will report status as amber because with a simple configuration change to vsphere replication, service levels can be met. In the third scenario, the Protection Tier calls for a 5 minute RPO. Architect would report a red status for Exchange, because it knows that the chosen protection strategy, in this case vsphere replication, is incapable of meeting this target under any circumstances. Disaster Recovery Assurance status is reported in multiple places: Within the Architect dashboard highlighting overall health of key business services. In the detailed view for each business service (see Figure 7). In the heat map view. This is the most useful tool for drilling down into protection assessment (Figure 9). In the Protection Assessment Report page 9

10 Figure 9: Protection assessment heatmap As mentioned earlier, each box in the heat map represents a dependent entity within a given business service. The heat map is designed to help the user prioritize their remediation efforts. A complex business service may comprise many dependent entities and the size of each box within the heat map is directly proportional to the number of dependencies associated with that entity. The heat color scheme associated with these boxes as indicated above in Fig. 9 is representative of how adequately protected or not a given entity is. As such, a large box within the heat map displaying prominent red color in most cases would be indicating that one of the more critical entities within the IT environment is at risk possibly due to inadequate protection. By drilling down into the large red boxes (double-click action) in the heat map view, the administrator can focus remediation efforts on the most critical components. Of course, Architect is only able to assess the protection status of protection infrastructure it knows about. In its initial release, Architect supports analysis of the following protection infrastructure: VMware High-Availability (HA) VMware Fault-Tolerance (FT) VMware vsphere Replication VMware Site Recovery Manager (SRM) Microsoft Cluster Server (MSCS) Neverfail Heartbeat Failover Engine This list will rapidly expand over subsequent releases to include other commonly deployed protection technologies. In the meantime, if your site uses a specific technology not directly supported, it may be profiled within the Continuity Architect database to set up recovery scope and performance characteristics. This will enable basic protection assessment analysis to take place. Continuous Monitoring for Disaster Recovery Assurance 1 Once Protection Tiers have been assigned to business services, Architect knows what Recovery Point, Recovery Time and Availability Service Levels are expected from the infrastructure footprint of that business service. Architect provides three separate monitoring services to assure the continued operation of an organization s business services within the parameters of these SLAs and proactively advise of any looming risks before they become an issue. 10

11 Infrastructure Change Monitoring If a business service is completely protected in line with its assigned tier, administrators and end-users will want to know of any changes which might compromise that situation. Architect will monitor for any changes in the configuration of protection technologies that reduces protection levels and puts the business service at risk. For example, if a VM inadvertently had HA switched off, was removed from a VMware Site Recovery Manager protection group, or had vsphere replication RPO increased, Architect will detect these changes, evaluate them against the assigned SLA targets and raise alerts if new levels of risk have been introduced. This form of monitoring will take place for all supported protection technologies. Furthermore, if a business service grows its footprint over time to include new dependencies, either applications or servers, then Architect will automatically detect these new dependencies and alert administrators to the risk and the need to review the new infrastructure. Figure 10: Aspects of Infrastructure Change Monitoring functionality within Architect Recovery Point Monitoring Many business services will include data protection as a policy requirement in their assigned tier with an associated Recovery Point Object (RPO) SLA. Data protection very often relies on replication technologies. The achievable Recovery Point for replication technology varies depending on a number of environmental issues including host, guest and network load. It is not uncommon for replication to falter to the extent that the actual Recovery Point is far worse than required and should disaster strike the recovery will fail to meet the expected SLAs. Architect will monitor the achievable recovery point the Recovery Point Estimate (RPE) in realtime for VMware vsphere Replication and Neverfail Heartbeat Failover Engine. Warning alerts are generated if the RPE rises above a configurable threshold and Critical alerts are generated if the RPO SLA is breeched. Figure 11: Aspects of Recovery Point Monitoring functionality within Architect Availability Monitoring Architect provides a predicted assessment of how likely it is that the detected protection technologies will support the assigned availability tiers. Administrators and end-users who have funded and implemented these solutions will want to know whether in fact these technologies actually deliver on the expected availability SLAs. Architect provides ongoing monitoring of all business services, 11

12 applications and servers that have a tier assigned to evaluate how well their availability matches requirements. Furthermore, Architect monitors and evaluates availability across dependency relationships so it can even detect when an outage of a modestly used server may have a ripple effect impact on the overall availability of an entire business service. Availability is tracked and reported upon relative to the rigors of the assigned tier. Any accumulated unplanned downtime which breaches a tiers SLA is announced as an alert. Architect also reports on the historical availability of all tier assigned infrastructure over any point in time. Summary Neverfail addresses the disconnect between business and IT by logically connecting the IT infrastructure and business services to ensure that IT gets the most out of its business continuity investments, while ensuring that disaster recovery plans work every time. Architect achieves this by first giving IT Managers and IT administrators a detailed understanding of what exists (often a time-consuming, manual and inaccurate exercise in itself), what is and is not protected adequately, and showing where dependencies exist that put key business services at risk. This gives IT the visibility and knowledge they need to connect the IT infrastructure to the business services it delivers, allowing them to assign and monitor service level objectives that meet the business requirements for IT continuity and disaster recovery. Neverfail created Architect to enable companies to bridge the gap between the IT infrastructure and its ability to support the business availability service level objectives, ultimately giving IT leadership the confidence that they will always be able to keep their business online. Neverfail s credentials to deliver this solution are unrivalled. We have spent the last 20 years helping companies with their business continuity strategies and delivering best in class continuous availability solutions to over 2,500 companies from the Fortune 50 to small businesses. We know better than anyone where the challenges lie. It was only through this experience that we realized the primary reason business continuity projects fail or are not funded: the disconnect between IT and the Business. 1 The continuous monitoring features are not available in the Technical Preview version of the product. These features will be offered in the upcoming General Availability release, scheduled for October Neverfail, Inc West Courtyard Drive, Suite 160B Austin, TX Tel: I info@neverfailgroup.com I 12