Hong Kong

+852 3464 1700


HIGH Availability as a Service (HAaaS)

HAaaS solutions provide a complete and intuitive approach that simplifies all aspects of IT continuity management: from initial analysis and planning through deployment, optimization and assurance of critical enterprise infrastructure availability.

With HAaaS, enterprises are free to use the latest virtualization technologies to deliver a more agile IT infrastructure without worrying whether their business continuity plans can keep up with the pace of change.

IT Continuity Architect

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.

The 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 insights to the impact of potential changes. This saves administrators hours of manual effort they would otherwise needed 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, and 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 would 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 is meeting service level commitments and keeping 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, 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, are recognized 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.

How IT Continuity Architect works

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:

Packaging and Deployment
Architect is packaged aa Linux-based Open Virtual Appliance (OVA) that registers itself as a VMware vCenter Server extension upon deployment. It can be downloaded from the Neverfail website 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.

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.

Neverfail believes that true continuous availability can only be delivered through the judicious and appropriate use of monitoring, detection and failover automation so that application issues can be resolved so rapidly that users are unaware that a problem even occurred. Any alternative solution that promises to recover from a disaster has, by definition, already failed to eliminate user downtime. This is the essential difference between reactive recovery-based solutions and proactive continuous availability from Neverfail. It’s also behind the decision by industry technology leaders, such as VMware and Solarwinds to license Neverfail technology to protect their customer’s critical infrastructure.

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:

  • 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

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 technologies from VMware, Microsoft, Veeam, and of course Neverfail are automatically recognized in this process. Server interdependencies are analyzed through network traffic analysis.

Another important design decision was to minimize the 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.

There are three distinct phases that yield increasing amount of information: initial Discovery; followed by Fingerprinting; and then Blueprinting:

  • 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.

Throughout the discovery process, progress is displayed in a portlet (figure 4) within Architect’s management console.

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 are 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.

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

  • Hypervisors

  • Operating systems

  • Protection technologies

  • Specific supported applications

  • Generic applications

  • User devices

  • Interdependencies between all of the above

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:

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.

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.

Business Services
The concept of a business service within Architect is fundamental in 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 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 minutiae of what IT services collaborate under the hood to deliver “email”.

In 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).

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.

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 the 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.

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 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:

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 the Dashboard and several other places. A heat map also shows business services that aren’t adequately protected (figure 10)

As mentioned 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:

  • VMware HA clustering

  • VMware FT clustering

  • VMware vSphere replication

  • VMware Site Recovery Manager

  • Microsoft MSCS failover clustering

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.