Highlights

Plans & Packages

Sify’s Synchronous Protect solution offers a custom built, cost effective, timely Tested, comprehensive solutions for your core applications across Hosting, Infrastructure, Operating systems, Database, Applications, Network services & managed services, with an RPO of near Zero and Customized RTO as per the business objectives.

The solutions are offered on our enterprise cloud platform or on a dedicated environment at our Tier III+ datacenters in Mumbai and Bangalore DC.

To know more about the prices, please click on “Have us call you” or email us at connect@cloudinfinit.com

Resources

Detail Description

Sify Synchronous Protect service offers a custom built, cost effective, timely tested, comprehensive solutions for critical applications with RPO of near zero and custom RTO as per your Business needs in Sify DC at Mumbai and Bangalore. The service is Custom built and integrated across the entire chain – infrastructure, hosting, network, OS, DB, applications etc. The solutions enable you to have

Synchronous Protect solution enables setting up a synchronous protect infrastructure and negates financial impacts due to downtime, protects your critical data and improves the employee productivity, Sify works with the customers in devising a Synchronous Protect plan with the detailed task list as below:

Synchronous Protection Operation:

If the primary site fails, the DR site needs to take over. However, the DR site may be behind the primary. That is, there may be some writes that are completed to the application but that have not reached the DR site data volumes; these writes are stored in the replicator Log on the near DR Site.

To recover from a disaster on the Primary, you can use the REPLICATION LOG on the near DR site to update the far DR site. You activate the near DR Site, which converts it to the primary role, and then the near DR site can replay the pending writes from the near DR Site REPLICATION LOG to the far DR site.

The procedure is similar whether the near DR site setup uses the IP protocol or uses direct storage near DR site replication enables you to balance the Recovery Point Objective (RPO) with the Recovery Time Objective (RTO) depending on your needs. In the case of a disaster, completely replaying the Near DR Site REPLICATION LOG to the DR site provides zero RPO.

However, the RTO depends on the time required to replicate pending writes from the near DR site REPLICATION LOG to the DR site. If the DR site is far behind the primary at the time of the disaster, the RTO could be large.

After all of the pending writes are transferred to the far DR site, the DR site is as up-to-date as the primary. In normal circumstances, if the entire REPLICATION LOG is replayed, the Far DR site can take over the role of the primary with no data loss. However, in certain failure conditions, the Near DR Site might not be able to bring the DR site exactly up-to-date with the primary. For example, if the LINK between the primary and the near DR Site was disconnected prior to the failure at the primary.

Near DR Site replication enables you to balance the Recovery Point Objective (RPO) with the Recovery Time Objective (RTO) depending on your needs. In the case of a disaster, completely replaying the Near DR Site REPLICATOR LOG to the DR site provides zero RPO. However, the RTO depends on the time required to replicate pending writes from the Near DR Site REPLICATOR LOG to the DR site. If the Far DR site is far behind the Primary at the time of the disaster, the RTO could be large.

Using Near DR Site replication, you can stop the replay after a period of time to recover as much data as possible within a target RTO. For example, if your DR site is 2 hours behind the Primary, you can replay the full Near DR Site REPLICATOR LOG to achieve zero RPO but the RTO would then be about 2 hours. If your target RTO is 1 hour, you could begin Near DR Site replay and then stop the replay after 1 hour.

If you need the application to be immediately available (RTO is zero), you can perform a normal DR site takeover, without replaying the Near DR Site at all. However, in this case, the pending writes in the Near DR site REPLICATOR LOG are lost. In order to use the Near DR Site REPLICATOR LOG to update the DR site, you must replay the Near DR Site before performing takeover on the Far DR site.

Note:

The Near DR Site can act in the DR site role, to receive updates from the Primary, or it can act in the Primary role, to send updates to the DR site during replay. However, it cannot perform both roles at the same time and therefore does not serve as a relay between a Primary and another DR site.

After the DR site has been updated (either the Near DR Site replay has completed or the target RTO is reached and the Near DR Site replay has been stopped), the DR site can take over the role of the original Primary. The Near DR Site for the original Primary cannot be used as a Near DR Site for the original DR site. Therefore, another suitable host near the new Primary can be configured as a Near DR Site for the new Primary

Service Deliverables

Sify’s Synchronous Protect Solution enables setting up a Synchronous Protect infrastructure and negates financial impacts due to downtime, protects your critical data and improves the employee productivity, Sify works with the customers in devising a Synchronous Protect plan with the detailed task list as below:

• Project Management of different activities and tasks as notified in the scope of the project.
• Setting up the infrastructure for the near DR and far DR site on CloudInfinit / dedicated environment for Hosting, datacenter network architecture, security components
• Establishing the user access to the DR site in case of disaster, setting up the connectivity layer for data replication
• Setting up the Replication between the primary, near DR & the far DR site along with the customer IT team.
• Working with the customer IT team to create a transition plan in moving the seed data from the primary site to the DR site.

The ongoing support specific to synchronous Protect managed service would comprise of the below support.

DR documentation & DR Drill after implementation,

• Work with the customer IT team to document the various activities associated with recovery of the systems.
• Development of a failover plan enlisting the steps / procedures to switch over services to the DR site in event of invocation of the disaster at Primary site, Also documentation of steps for restoring the services from the DR site to the primary site.
• Assign responsibilities between Sify, customer IT Team and any third party vendor (if involved), for the tasks and activities associated for invoking the DR.
• Perform a DR drill after implementation to test the failover and failback process, establish RPO, RTO & finalize the documentation.

24 X 7 Monitoring of Data replication:

• Perform a 24 X 7 monitoring of the data replication between the primary and the DR site.
• Connect with the customer IT team, for any issues or errors noticed in the data replication between the primary & DR site
• Work with the customer IT team for transferring data to the DR site, in case of replication link failure.

Emergency support – Failover

• Perform tasks and activities as documented in the DR document, once the DR has been declared by the customer
• Tasks related to the failover includes
  • Bringing the server up
  • Mounting the correct version of the database
  • Perform DNS changes & network changes, if documented in the DR scope.
  • Assist the customer IT team for carrying out any changes in the application configuration changes, if required to be performed
  • Perform additional tasks as mentioned in the DR documentation.

Failback Support to Primary site:

• Perform tasks and activities as documented in the DR document, for migration to the primary site from the DR site.
• Transfer the modified data as per customer requests to the primary site or provide the complete data in the Hard disk or tapes to the customer IT team, as per requests

Change Management & Service Requests:

• Document a Change management process for ensuring the changes done at the primary site on the OS & DB are replicated at the DR site.
• Incident Management, Problem Management during DR and Non DR time
• Service requests for any new installation, monitoring additional databases & appending DR documentation

DR Drills:

• Create a DR drill document defining the process, procedures and roles / responsibilities between Sify and the customer team
• Perform half yearly DR drills in association with the customer IT team as per the above plan

Remediation & Gap analysis:

• Publish the gaps reported during each DR Drill with the customer and devise an action plan for resolution for the gaps.

Helpdesk – 24 X 7

• 24 X 7 Help desk for any emergency support related to DR Failover.
• Engagement manager for the customer support.

Reporting

• Reporting to the customer for meeting their compliance needs, RPO, RTO dashboard, infrastructure reports, network reports