The Business Continuity Gap
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 in to 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 faces a number of challenges:
- Lack of visibility in to how the IT infrastructure maps to business services
- Unknown impact of infrastructure changes on IT’s ability to meet service levels
- Difficult to justify business continuity investments without clear insight in to critical dependencies and risks
Neverfail IT Continuity Architect provides clear visibility in to how your IT infrastructure and continuity readiness map to the business, and identification of any potential downtime risks.
Neverfail IT Continuity Architect
Neverfail IT Continuity Architect bridges the gap between IT infrastructure and business services so IT can trust their business continuity plans will always work. Architect automatically analyzes IT infrastructure, maps dependencies and tracks changes, showing you what is at risk and what you need to do to assure continuity without fail. By letting IT set recovery time and recovery point objectives (RTO and RPO) by application, Architect allows companies to decrease the risk of outages, reduce the cost of disaster recovery infrastructure and maintain compliance with service level commitments. Downtime puts your reputation at risk; Architect helps you avoid it.
The IT Continuity Architect Dashboard
The Architect dashboard, a VMware vSphere Web Client plug-in, provides key information about the infrastructure, business services and whether or not IT can meet business continuity objectives.
IT Continuity Architect Features
Automated Infrastructure and Dependency Discovery
Upon install, Architect automatically begins discovering IT infrastructure and the associated dependencies. Within minutes, Architect identifies IT infrastructure components and provides a map of dependencies between applications, hypervisors, servers and other inventory objects, giving IT insight in to the impact of potential changes. This saves administrators hours of manual effort they would otherwise need to spend identifying and cataloging the infrastructure, applications and the various dependencies.
Business Services Mapping
Architect lets administrators easily define business services and map those automatically to the underlying IT infrastructure. Architect aggregates IT infrastructure and applications into groups based on their interdependencies. Users can easily define business services and visualize the IT infrastructure supporting each service. With Architect, administrators can understand which IT components are the most important to the business, and how business services map to IT infrastructure.
Define Business Continuity Targets
With Architect IT managers 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 users can customize to define their own targets, then assign each business service to the appropriate tier. Architect automatically reports on any gaps or misconfigurations of protection infrastructure. This lets IT know in advance if there are any gaps in the organization’s protection strategy that put the business at risk.
Risk Identification Heat Maps
Architect’s visual heat map helps prioritize remediation efforts based on risk. 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 IT intelligently prioritize remediation efforts for systems that are out of compliance. Intuitive representation of infrastructure identifies the most critical IT components so administrators know what gaps to fix first.
Availability Monitoring and Reporting
Architect provides ongoing and continuous monitoring, assurance and reporting of service level compliance. By automating the discovery of new or updated IT infrastructure, Architect dynamically ties changes to service level targets. IT can proactively manage and report on business continuity preparedness and compliance. Architect lets IT managers automatically assure that the organization can meet service level commitments and keep the business online.
How IT Continuity Architect is Different from Existing Tools
For IT Infrastructure & Operations Professionals, Virtualization Administrators, Datacenter Architects and Disaster Recovery Managers, Neverfail IT Continuity Architect provides a way to understand how business services connect with the underlying IT infrastructure so that they can be assured business continuity plans will always work. The IT Continuity Architect is designed to work across your entire server inventory regardless of the protection technology in use in the environment. Availability & backup solutions from VMware, Microsoft, Veeam, and of course Neverfail, are recognised automatically by the IT Continuity Architect.
While every IT professional has access to inventory and discovery tools, it takes manual, time-consuming effort – spreadsheets, runbooks and detailed analysis to connect the IT infrastructure with business requirements. Architect bridges the gap by constantly monitoring IT availability targets, connecting changes to the underlying infrastructure to the risk they pose to the business. It provides the only automated solution for business continuity operations, delivering assurance that disaster recovery plans will work as intended.
- Packaging and Deployment. Architect is packaged asa Linux-based Open Virtual Appliance (OVA) that upon deployment registers itself as a VMware vCenter Server extension and installs in less than 10 minutes.
- 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.
- Show relationships and dependencies between infrastructure components, applications and business services
- Identify any gaps in the business continuity infrastructure
- Model the impact on business continuity readiness of potential changes
- 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.
- Servers (physical and virtual machines)
- Operating systems
- Protection technologies
- Specific supported applications
- Generic applications
- User devices
- Interdependencies between all of the above
- 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.
- VMware HA clustering
- VMware FT clustering
- VMware vSphere replication
- VMware Site Recovery Manager
- Microsoft MSCS failover clustering
Neverfail IT Continuity Architect Technical Overview
The concepts and technologies that Architect employs to discover, analyze, monitor and model production IT inventory to deliver value to its users are described in more detail here. Architect works through a simple and streamlined process, beginning with deployment:
Figure 1 – Architect Dashboard
Neverfail Architect in Detail
Architect works by first discovering the environment and presenting the results in the dashboard, then seeks additional inputs from administrators, such as system credentials or definition of business services (see Figure 2). Through ongoing analysis of the infrastructure, Architect is able to:
Figure 2 – How Architect works
Discovery, Fingerprinting and Blueprinting Process
Once installed, Architect will commence its Discovery phase, during which it compiles an inventory of server assets, through interrogation of vSphere catalogs and agentless discovery of non-vSphere assets.
Further Fingerprinting takes place to discover what existing virtual or physical clustering and disaster recovery infrastructure has been deployed. Protection technology from VMware, Microsoft, Veeam, and of course Neverfail is automatically recognized in this process. Server interdependencies are analyzed through network traffic analysis.
Another 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.
Figure 3 – Object Discovery
There are three distinct phases that yield increasing amounts of information: initial Discovery; followed by Fingerprinting; and then Blueprinting (see figure 2 above):
Throughout the discovery process, progress is displayed in a portlet (figure 4) within Architect’s management console.
Figure 4 – Discovery progress reporting
The Architect Heat Map: Blocked Entities
The heat map (Figure 5) in Architect can be used in a number of ways. In this example, some entities arebe blocked from further analysis pending provision of new security credentials. The Architect heat map helps users prioritize efforts to provide credentials for blocked servers – the larger the rectangle, the more infrastructure that entity supports.
Figure 5 – Discovery Heat Map
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):
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:
Figure 6 – Suggested Architect workflow
Explore and Analyze Results
In the third activity shown in Figure 6, Architect offers some intuitive tools to explore and analyze the results of discovery. Datacenter or Enterprise Architects and IT Directors 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 7.
Figure 7 – Architect’s dependency graph
Architect also provides detailed information for each analyzed entity showing core attributes and protection status. In order to allow an entity’s protection status to be derived by Architect, the user must continue through steps 4 and 5 of the workflow above (Figure 6) and define a set of business services (e.g. the “email” service). This lets Architect associate all interdependent IT infrastructure within, for example, the “email” service, and then allows the user to apply a protection tier for the entire service.
The concept of a business service within Architect is fundamental to extracting the Disaster Recovery Assurance value that the product delivers. A business service is an aggregation of IT components that ultimately supports a discrete function that a business 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 “email” 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 “email”.
By contrast, I&O professionals are very interested in making sure that all of these collaborating IT services that deliver “email” are adequately protected so that email is always available. Architect provides a view of each business service that shows its dependent IT components (Figure 8).
Figure 8 – 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.
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 site policy. These settings define scope of protection (local clustering, remote DR) and performance of protection (availability targets, RTO, RPO), as shown in Figure 9.
Figure 9 – Protection Tier settings
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 IT component to determine whether or not it will meet the required service level agreement (as set out in the Protection Tier).
Let’s take the example of an email service where it is not adequately protected:
Disaster Recovery Assurance status is reported in the Dashboard and several other places. A heat map also shows business services that aren’t adequately protected (figure 10).
Figure 10 – Protection assessment heatmap
As before, 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 if a large number of these are inadequately protected, the size of each box in the heat map shows which entities have the most interdependencies. By double-clicking on the largest box the administrator can focus remediation efforts on the most critical components.
Architect currently supports assessment of the following protection infrastructure:
This list will rapidly expand over subsequent releases to include other commonly deployed technologies. If your site uses a specific technology not directly supported, it can be added directly within the Architect database and assigned recovery scope and performance characteristics. This will enable basic protection assessment analysis to take place.
Continuous monitoring of DR Assurance
Once Protection Tiers have been assigned to business services, Architect knows what recovery point and recovery time objectives have been assigned. If the “email” service requires a one hour recovery target, then Architect will automatically scan all dependent infrastructure for changes that may impact the ability to meet the business continuity targets. The assessment intervals are based on the protection tier assigned, so a Tier 1 business service will be scanned more frequently by default.
Register today to request a free trial of Neverfail IT Continuity Architect and see for yourself how it can add value in your specific environment. We know that you will be impressed. When you're ready to buy simply contact us to complete your subscription!
"Architect’s discovery and dependency mapping capabilities are both far more powerful than our existing tools and much easier to deploy and use."