Discover Technology: April 2015

1. What is a partition

Physical partition:

Resources are allocated in physical building blocks.

Blocks contain groups of processors, memory, and I/O slots

Logical partition

A partition is the allocation of system resources to create logically separate systems within the same physical footprint.

A logical partition exists when the isolation is implemented with firmware:

Not based on physical system building block

Provides configuration flexibility

Partition characteristics

Each partition has its own:

Operating system

Licensed internal code (LIC) and open firmware

Console

Resources

Other things expected in a stand-alone operating system environment, such as:

Problem logs

Data (libraries, objects, file systems)

Performance characteristics

Network identity

Date and time

Resources are allocated to partitions:

Memory allocated in units as small as the LMB size.

Dedicated whole processors or shared processing units.

Individual I/O slots.

Including virtual devices

Some resources can be shared:

Virtual devices.

Host Ethernet adapter.

Some core system components are inherently shared

Benefits of using partitions

Capacity management:

Flexibility to allocate resources.

Consolidation:

Consolidate hardware, floor space, software licenses, support contracts, and in-house support and operations.

Efficient use of resources.

Application isolation on a single frame:

Separate workloads.

Guaranteed resources.

Data integrity.

Merge production and test environments:

Test on same hardware

2. POWER Hypervisor functions

The POWER Hypervisor is firmware that provides:

Virtual memory management:

Controls page table and I/O access.

Manages real memory addresses versus offset memory addresses.

Virtual console support

Security and isolation between partitions:

Partitions allowed access only to resources allocated to them (enforced by the POWER Hypervisor).

Shared processor pool management

3. Advanced partition

Dynamic Logical Partitioning (DLPAR)

DLPAR is the ability to add, remove, or move resources between partitions without restarting the partitions.

Resources include:

Processors, memory, and I/O slots.

Add and remove virtual devices.

Security and isolation between LPARs are not compromised.

A partition sees its own resources plus other available virtual resources.

Resources are reset when moved.

Applications might or might not be DLPAR-aware

Processor concepts

Micro-partitioning: Shared processor pool

Time sliced sub-processor allocations are dispatched according to demand and entitled capacity.

This example shows one 10 ms time slice, seven running partitions, and four processors

Multiple shared processor pools

Virtual I/O

Each partition has virtual I/O slots.

Configurable for each partition.

Virtual slots have a virtual adapter instance.

Serial, Ethernet, SCSI, or Fibre Channel.

Virtual I/O slots can be dynamically added or removed just like physical I/O slots.

Cannot be dynamically moved to another partition

Integrated Virtual Ethernet

Also referred to as host Ethernet adapter:

Included in many POWER6 and POWER7 system configurations.

Provides network connectivity for LPARs without a Virtual I/O Server:

Integrated high-speed Ethernet ports with hardware-assisted virtualization capabilities.

Offers virtualization support for Ethernet connections.

Depending on the system model, multiple types are available:

Two port 1 Gba

Four port 1 Gba

Two port 10 Gbb

Two 10 Gbb and two 1 Gb portsa

Connected to the GX+ bus:

An LHEA must be created on the logical partition.

Active Memory Sharing

Active Memory Sharing (AMS) allows multiple LPARs to share a common pool of physical memory.

AMS intelligently assigns memory from one partition to another based on memory page demands.

Optimizes memory utilization and provides flexible memory usage

Active Memory Deduplication

Active Memory Expansion

Compresses in-memory data to fit more data into memory:

The physical memory requirements of existing LPARs is reduced.

Free memory capacity can be used to create more LPARs.

Increases a LPAR’s effective memory capacity:

Can increase the effective memory capacity of a LPAR.

Increases the memory available to a workload.

Live Partition Mobility

Migration or movement of an LPAR from one physical server to another.

Useful for:

Reducing the impact of planned outages and increasing application availability.

Workload balancing and consolidation.

Relocation of workload to enable workload.

Provision of new technology with no disruption to service (migration to newer systems).

Requirements:

–POWER6 or POWER7 systems.

–LPAR must only have virtual adapters.

Shared storage pools
Shared storage pools:
Provide distributed access to storage resources using a cluster. Shared storage pools use files called logical units as backup devices for virtualized storage devices.
Benefits:
•Simplify the aggregation of large numbers of disks across multiple Virtual I/O Servers.
•Improve the utilization of the available storage.
•Simplify administration tasks.

1. Overview

As you investigate various replication solutions, you notice that with each approach to replication, synchronous or asynchronous, several key areas must be understood. EMC typically refers to these as the “pain points” of remote replication. They are:

The impact on response time of your production application. For example, with a remote-synchronous solution, your application must wait for the acknowledgement from the remote system before proceeding with the next dependent write. You also have speed-of-light issues, which impact the maximum distance your locations can be from each other.

The infrastructure – What additional equipment do you require to support the replication process?

The communication links – How big and how expensive will the communication link need to be in order to support the process?

And, most importantly, what is the recovery point at the target? That is, how much data exposure do you experience as part of the operation; none, seconds, minutes, hours?

Each of these pain points must be carefully balanced. Without choice and flexibility, you cannot begin to architect a solution that meets your particular replication service levels. One of the best ways to appreciate RecoverPoint is to look at how these pain points are addressed by this technology.
RecoverPoint offers the following capabilities:

Integration with existing (heterogeneous) storage arrays, switches, and server environments – no “rip and replace.”

Intelligent use of bandwidth and data compression that enables supporting data centers that, due to regulatory requirements, have established a large physical separation between their primary and secondary sites, without requiring expensive, high-bandwidth, long-distance WAN connections.

A policy-driven engine that supports multiple applications with different data-protection requirements (recovery, corruption, testing, etc.).

RecoverPoint Fundamentals True bi-directional local and remote support, enabling flexible protection and recovery schemes that can be tailored to business processes.

EMC RecoverPoint is an enterprise-scale solution designed to protect application data on heterogeneous SAN-attached servers and storage arrays. RecoverPoint provides many features that make it a unique and tested solution for backup and recovery.
RecoverPoint allows for the access of a point-in-time image, either locally or at another site, while still performing replication. The ability to access data from a copy allows for testing without sacrificing protection. This feature also is integrated with various applications, such as Exchange, SQL, and VMware. This allows for application-driven point in time copies. RecoverPoint also can be used with VMAX’s SRDF feature to create additional protection.
Point in time copies can be created for each write, or the user can choose the amount of data lag that can be tolerated for an application. This option is configurable for each group of volumes, and can be edited at any time.

RecoverPoint provides many features and benefits that build on previous RecoverPoint versions. The multiple sites feature allows you to keep up to four individually journaled copies of your production data, enabling greater data protection, increased access to different point-in-time (PIT) copies, and a wider range of DR, testing, and backup topologies. And with synchronous replication over IP, one of these remote copies can be a synchronous copy without the need for remote fibre connectivity. The introduction of vRPAs relieves the need for physical RPAs.
The introduction of Unisphere for RecoverPoint allows for consistent management interfaces and methodologies across EMC technologies.
The RecoverPoint REST API interface enables custom scripting and applications via standard RESTful protocols.
Improved integration with VMware Site Recovery Manager (SRM) allows for testing and failover to any point-in-time copy. Integration of RecoverPoint local replication and SRDF allows for local journal copies in conjunction with remote SRDF copies. This enables access to any local point-in-time copies, while still maintaining SRDF functionality

RecoverPoint provides local data protection and replication for virtual machines. It uses continuous data capture for local SAN data protection in order to: protect the virtual machines, protect the ESX server platform from data corruption, and to guarantee recoverability locally with no data loss. RecoverPoint also supports virtual-to-virtual replication between equivalent storage configurations, such as VMFS to VMFS or RDM/P to RDM/P. This support uses the VNX series or CLARiiON array-based write splitter. Similarly, RecoverPoint supports physical and physical-to-virtual replication. It also supports virtual-to-virtual replication using host-based RecoverPoint write splitters installed in each guest operating system. Physical RDM(RDM/P)-attached volumes are replicated locally and/or remotely.
RecoverPoint’s VMware support can be used to enhance existing VMware vMotion and Storage vMotion solutions. RecoverPoint integrates with vCenter Server to allow the RecoverPoint administrator to quickly view virtual machines fully protected by RecoverPoint. For those not fully protected, it allows the administrator to see which of the virtual machine’s LUNs/data stores are not protected. Additionally, RecoverPoint is integrated with VMware vCenter Site Recovery Manager to simplify and automate disaster recovery in VMware Infrastructure. RecoverPoint also has a vCenter Server plug-in that automates failback for SRM configurations.
The RecoverPoint management GUI can be used to monitor

2. Case Study

It includes a single production Oracle 11g database on a Symmetrix VMAX 10K. EMC RecoverPoint splitter is leveraged for continuous local and remote replication. The recovery site is built on an EMC VNX 5700. VMware vCenter Site Recovery Manager with EMC Site Recovery Manager Adapter for RecoverPoint is leveraged, and enables management across the two sites

RecoverPoint is also integrated with VMware vCenter Site Recovery Manager. Virtual machines can be brought back online rapidly with no data loss when RecoverPoint is used with VMware vCenter Site Recovery Manager to orchestrate and streamline data protection and failover processes. RecoverPoint is the most flexible approach to protecting virtualized data – replicating VMware vStorage VMFS to protect and recover a single virtual machine or the entire VMware ESX server

3. Architecture

A RecoverPoint system is all of the RecoverPoint components that are used to replicate and protect data. A system can include a single RecoverPoint cluster or many connected together. A RecoverPoint system consists of: RecoverPoint appliances (physical or virtual), RecoverPoint Clusters, Write splitters, and RecoverPoint volumes.

With RecoverPoint 4.0 and later, a RecoverPoint system can replicate data to up to four remote copies. Shown here is an example with all four copies in four different remote clusters. Each of these copies has its own journal and can be individually accessed. If we had a local copy, we could have up to three remote copies. Having two remote copies in the same remote cluster is also a supported configuration. Please note that RecoverPoint/SE supports a maximum of two clusters.

Additionally, RecoverPoint 4.0 supports synchronous replication to a remote copy over IP. Previously, this was only supported with fibre connectivity. Regardless of whether over fibre or IP, only one remote copy per RecoverPoint consistency group can be replicated synchronously. Since a local copy can also be synchronous, this means that RecoverPoint can maintain two synchronous copies at the same time. A general guideline for synchronous replication over IP is for the link to have a latency (round-trip) less than 10 ms.

Multi-cluster configurations allow for greater protection, increased access to PIT copies, and implementation of a wide range of disaster recovery, testing, and backup topologies. It also enables a single point of management and minimizes the number of RPAs required compared with previous shared splitter solutions.

RecoverPoint uses software running on the CPUs of the arrays to perform Write-Splitting. This software copies all incoming writes for volumes protected with RecoverPoint. A copy is written to the production volume and a copy is sent to the RecoverPoint appliance. Previous versions of RecoverPoint used Write-Splitters located on the Host or SAN. RecoverPoint 4.0 and above only uses the array-based version of Write-Splitters.

The VNX/CLARiiON splitter runs in each storage processor of a VNX and splits (“mirrors”) all writes to a VNX volume, sending one copy to the original target and the other copy to the RecoverPoint appliance.
Both RecoverPoint and RecoverPoint/SE support the VNX/CLARiiON splitter. The VNX/CLARiiON splitter is supported on VNX arrays, as well as CLARiiON CX4 UltraFlex™ arrays.
The VNX/CLARiiON splitter is supported on both iSCSI and FC attached volumes.

4. RecoverPoint Appliance (RPA)

RecoverPoint Appliance (RPA) is the data-protection controller for RecoverPoint. RPA nodes utilize private LAN and shared RPA volumes for communications using standard TCP protocol. No FC/IP converters are needed to replicate across the WAN. The set of RPAs at each cluster constitutes an RPA cluster, where each cluster can include between one and eight RPAs, as set during RecoverPoint system installation.

The cluster size must be the same at all clusters in an installation. In normal operation, all RPAs in a cluster are active all of the time. Consequently, if one of the RPAs in a cluster goes down, the RecoverPoint system supports immediate switchover of the functions of that box to another RPA in the cluster.

Generation 5 RPAs perform hardware status notifications. If a hard drive or power supply on the RecoverPoint appliance fails, a hardware event notification will be raised in the system logs. If configured, the event will also create a call-home event, sending a system request to EMC Customer Service. Call home events can be suppressed during maintenance periods to avoid Service Request generation.

RPAs are deployed in a two-to-eight-node cluster configuration that allows active-active failover between the nodes. The RecoverPoint environment can consist of up to five clusters which can either be local or at different locations.
Each RPA has the following interfaces:

Four Fibre Channel ports used for data exchange with local host applications and storage subsystems, providing redundant connectivity to the SAN-attached storage and the hosts.

One Ethernet interface used to transfer data to other clusters.

One Ethernet interface used to manage the RecoverPoint system So as seen in this slide, a 2-node cluster would consist of:

Eight Fibre Channel connections (Gen4: 2 nodes x 1 HBAs per node x 4 ports per HBA – Gen3: 2 nodes x 2 HBAs per node x 2 ports per HBA)

Four Ethernet connections (one management LAN connection and one data WAN connection – per node)

Five IP addresses (2 nodes x 2 Ethernet connections + 1 floating IP address for management)

In preparation for RecoverPoint deployment, ensure that there is one RPA Fibre Channel port available per RPA per fabric. This ensures high availability by providing redundancy between all components at the cluster.
A dual fabric configuration is required at all clusters for RPA, host, and storage connectivity.

A special volume must be dedicated on the SAN-attached storage for each RPA cluster. This volume stores configuration information about the RPAs, the cluster, and consistency groups. This enables a properly functioning RPA to seamlessly assume the replication activities of a failing RPA from the same RPA cluster.
There is a Repository volume for every RecoverPoint cluster. The volume is presented to each RPA, either via the SAN or using iSCSI for virtual RPAs.

Each copy of data in a consistency group must contain one or more volumes that are dedicated to holding point in time history of the data. The type and amount of information contained in the journal differs according to the journal type. There are 2 types of journal volumes:

Copy Journals

Production Journals

Journal volumes hold snapshots of data to be replicated. Each Journal volume holds as many point in time images as its capacity allows, after which the oldest image is removed to make space for the newest. Journals consist of 1 or more volumes presented to all the RPAs for the cluster. Space can be added, to allow a longer history to be stored, without affecting replication.
The size of a Journal volume is based on several factors: