State Data Centre Disaster Recovery Strategy Document Version 1.0

Transcription

1 State Data Centre Disaster Recovery Strategy Document Version 1.0

2 Table of Contents SDC DR Strategy Document: Version 1.0 Chapter 1: Introduction Objective DR Site Assumptions Important References... 6 Chapter 2: Disaster Declaration Criteria... 7 Chapter 3: Disaster Categorization Intensity of disaster Disaster Scenarios... 9 Chapter 4: Categorisation of Applications Chapter 5: Prevention Strategies / Fault Tolerance Chapter 6: Stakeholder Analysis Chapter 7: Security Analysis during Disaster Recovery Chapter 8: System Level Disaster Recovery Plan Chapter 9: Detailed SDC DR Architecture and Design Chapter 10: Disaster Recovery Teams Composition Annexure A : SDC DR Services available at the DR Site (NDC) Annexure B : Replication Solutions Annexure C : SDC NDC Mapping DIT, Government of India Page 2

3 Abbreviations SDC DR Strategy Document: Version 1.0 DIT NIC SIA DCO TPA SI NIC CT UD RTO RPO Department of Information Technology, Government of India National Informatics Centre State Implementation Agency Data Centre Operator / Bidder Third Party Agency System Integrator National Informatics Centre Composite Team User Department Recovery Time Objective Recovery Point Objective DIT, Government of India Page 3

4 Chapter 1: Introduction SDC DR Strategy Document: Version 1.0 As per the National egovernance Plan (NeGP), State Data Centres (SDC) are being set up in all States / UTs of India to support various State Departments in running their applications catering to G2G (Government to Government), G2C (Government to Citizen), and G2B (Government to Business) services. With the maturity of SDCs and hosting of States applications and data, it has become imperative to provision a mechanism to secure the critical data of States. The Disaster Recovery (DR) Strategy Document, is a step in this regard. DR Strategy is a guideline document aimed to assist the formulation of a DR Plan and DR Implementation methodology of the States. It has been identified for each State to create its Disaster Recovery Plan through the use of the DR Handbook and DR Strategy documents. This Document, titled State Data Centre Disaster Recovery Strategy Document has been prepared by DIT, Government of India to assist the States for their Disaster Recovery Plans. This Document contains components needed by the State to prepare their DR Plan and be prepared in the event of a Natural / Man-made Disaster. This document describes criteria for Disaster declaration, various risks involved, Fault Tolerance mechanisms to follow in case of outages, and Stakeholder Analysis containing information on the various Stakeholders and their Roles & Responsibilities in the entire DR Process. After going through this document, the States would be able to freeze on the activities to be performed in order to be ready for an effective DR. Also, since NIC is an active stakeholder in the DR lifecycle for SDC, services & facilities available at the NIC managed DR Sites have also been defined in the present document. 1.1 Objective To define a Strategy for effective recovery of all critical IT applications in a swift and seamless manner. To mobilize all resources of SDC in terms of People, Process, and Technology, for DR. 1.2 DR Site DIT, Government of India Page 4

5 Every Data Center in the State has at least approximately10 to 20 applications, Departmental websites and Portal which require services ranging from data backup to Disaster Recovery to BCP depending on the criticality of the application and data. National Data Centres, managed by NIC, have been identified as DR Sites for the SDCs. An appropriate SDC - NDC mapping has been prepared by NIC in consultation with DIT, to reflect on each SDC terminating on an appropriate NDC for its DR requirements. The same may be seen at Annexure C. Each NDC shall support the DR for mapped SDC zones through services, described in detail in Annexure A. The major objective of having DR facility for SDC at National Data Centres is to ensure reliable Data Backup and Periodic Replication based on the Replication solution for the State. (A brief description of Replication Solutions offered by the Industry are described in Annexure B) 1.3 Assumptions For the Disaster Recovery plan formulation, a number of assumptions shall be taken into account before deciding the readiness of a SDC to initiate a DR, such as:- All User Department applications in the scope of Disaster Recovery are assumed to be critical to SDC s operations. Plan has been envisaged for SDC personnel and systems to be prepared for the worst case scenario in terms of maximum damage owing to the disaster. The identified DR Site has all the requisite Hardware and Software availability for DR. All key personnel shall be available immediately, in the event of a disaster, so as to perform the allotted duties accordingly. In addition, all User Department / SDC vendors will perform according to their commitments for support of SDC during a disaster. All critical data required for Disaster Recovery is readily available. Procedures for back-up and off-site storage of computer media and paper files have already been followed. Critical Third-party resources listed in the DR Plan are available from identified suppliers or off-site storage facilities. The Disaster Recovery Plan will serve as a set of guidelines, not absolute rules. It is not allinclusive. Decisions not expressly documented within, are to be made by the Crisis Management Team (CMT) during the recovery process. DIT, Government of India Page 5

6 1.4 Important References While all activities required for formulating an efficient SDC DR Strategy are required to be done independently, there are specific parameters of some activities that overlap with other activities expected to be undertaken at the SDC as part of specific functions at the SDC. Following is a list of reference documents that may assist the State in specific DR Strategy planning activities: Document Name Original Purpose of Document Reference for DR Strategy SDC DR Handbook Document Disaster Recovery Planning SDC DR Business Impact Analysis, DR Teams Roles & Responsibilities SDC Information Security Information System (ISMS) Risk Assessment Report ISMS set up at the SDC for ISO Certification Risk Assessment for DR Planning DIT, Government of India Page 6

7 Chapter 2: Disaster Declaration Criteria Not every Security breach is a Disaster, and not every Power outage a reason to declare a Disaster. Following are the Disaster exclusions, i.e., events that do not qualify to invoke a Disaster Recovery scenario: Known Data Center equipment malfunctioning, where procedures and guidelines are already known to SDC on the recovery of the same. Any event covered under the Prevention Strategies/Fault Tolerance at SDC, defined in Chapter 2. Network spikes caused owing to high traffic flows and not due to any equipment / Software issues. Resignation / extended unplanned Leave of any Data Center employee, however critical he / she may be to the daily Data Center operations. Virus / Spamming attacks on a single Server causing an isolated application outage. Any non-critical application shutting down, irrespective of the down time duration Planned Individual critical DR application shut down for a period less than the Defined DR RTO. Natural Calamity in the neighboring areas not bound to affect Data Center premises / operations. Broadly, threats that are bound to affect any SDC have been defined below: Fire/ Explosion Earthquake/ Floods Power Outage Air Conditioning Failure Political/Civil Unrest/ Internal Strikes Theft Lightning/ Heavy rains/ Storms Pests Vendor Support Failure Bombing Virus attack Denial of Service Network Penetration/ Internal- External Hacking WAN Link Failure Hardware Failure Software Failure etc All threats mentioned above are potent to cause a Disaster. However, the States shall be methodological in their approach to apply procedures like Fault Tolerance, and ISMS controls, in order to prevent a risk from escalating to causing a Disaster. DIT, Government of India Page 7

8 Chapter 3: Disaster Categorization 3.1 Intensity of disaster The intensity of a Disaster is a function of, which or how many of the critical resources are no longer available to the business. To help the planners and the Department Heads to chart out an appropriate DR strategy, the analysis of possible Disasters was classified into 4 levels of intensity. Level Description Level 1 Failure impacting single Department Significant malfunction of/disruption to primary infrastructure supporting operations of a single Department. e.g., Application failure Level 2 Failure impacting multiple Departments Significant malfunction of/disruption to critical primary infrastructure, supporting operations of multiple Departments. For e.g., failure of any of the critical primary servers or data storage systems Level 3 Premises unavailable Total shutdown of office infrastructure, as a result of fire, building collapse, bomb explosions etc. since the premises and equipments are inaccessible, people may have to congregate at an alternate location, if required. Level 4 Citywide disaster Major impedance to employees trying to reach office or alternate office resources - e.g. due to riots, floods or other major citywide catastrophe. DIT, Government of India Page 8

9 3.2 Disaster Scenarios A number of scenarios may exist for SDC that may be potentially fatal for Disaster Declaration, caused by Threats as mentioned in the preceding chapter. The intensity of disaster has already been defined in the previous section. These impacts are bound to cause disruptions to the functioning of the SDC in terms of People as well as the IT Infrastructure placed at the SDCs. A Disaster, thus, may be defined through the context of these disruptions. Disaster recovery strategies are described below through a matrix that takes into account various scenarios any event could disrupt the smooth functioning of the SDC: Location of Manpower for Location of IT Whether valid Action Operations and functioning Disaster Maintenance Infrastructure Scenario SDC SDC No Normal Operations SDC NDC Yes S1 Other Site / NDC SDC No Remote Handling NDC NDC Yes S2 From the table above, it can be seen that whenever the IT infrastructure at the NDC becomes the primary functioning candidate due to unavailability of the infrastructure at the SDC, a Disaster may be declared. The Disaster Strategies to be adopted in turn shall be different for each kind of Disaster. Below are the descriptions of such Strategies: Scenario Description Scenario-I (S1) Operating from Primary site using DR infrastructure (No people movement) This strategy is applicable when critical systems are unavailable at the Data Centre. However the Primary site is accessible and connectivity to the DR site is available. In such cases, the employees can remotely DIT, Government of India Page 9

10 access and start the systems at DR site. Since, this would also involve some level of coordination between the personnel at the Primary and DR site; it is required to have relevant support at the DR Site. However, it must be ensured that critical data needed for Recovery is available at the DR site before system start up. Remote Handling Operating from Remote logging using the infrastructure at Primary site This strategy may be used in case of events like citywide disruptions which may potentially make the Primary site inaccessible to employees. The application systems are not affected at Primary infrastructure site and could be accessed from elsewhere (e.g. working from home). An SDC Disaster may not be declared in this case. This scenario involves active coordination from the Help Desk in getting the concerned team members connected through tele-conferencing, etc. This Strategy involves constant communication with the State Law enforcement teams. In case the SDC premises is expected to be affected, DR Strategy S2 can be initiated pro-actively after relevant communications among all stakeholders. Scenario-II (S2) Operating from DR site using the DR infrastructure This strategy may be used in case of a disaster that results in unavailability of the city hosting the Primary site (i.e. the premises, technology and infrastructure in the city hosting the Primary site are either unavailable or inaccessible). City wide disasters, terrorist attacks, etc. are some of the events that may result in such a failure scenario. Critical Departmental teams can work from home with DR site infrastructure in such scenarios. The following table maps the possible recovery strategies to identify the intensity of event and various scenarios identified. However this list is not comprehensive and may need revision based on the learnings of the Risk Assessment to be carried out at the SDC. The appropriate strategy will have to be selected based on the environmental conditions at the time of the disaster. DIT, Government of India Page 10

11 Sl. No. Incident Level Impact Resources Affected Result Applicable Strategy 1. Fire / Explosion L3 Premises IT Infrastructure / Primary site not available. S2 People 2. Earthquake L4 Citywide IT Infrastructure / Employee Shortage, Non S2 People Availability of Primary site for extended period 3. Power Outage L2/L3 Premises IT Infrastructure / Primary site not available. S2 People 4. Air-conditioning failure L1/L2 Premises IT Infrastructure / Primary site not available. S1 People 5. Political / Civil Unrest / L4 Citywide People Most offices of city not Remote Riots / Internal Strike accessible. Handling 6. Theft / Unavailability of components L2/L3 Premises IT Infrastructure SDC server systems affected S1 7. Heavy Rains / Floods L3/L4 Citywide IT Infrastructure / Most offices of city not Remote People available. Handling, DIT, Government of India Page 11

12 moving to S2 8. Lightning / Storms L3/L4 Citywide IT Infrastructure / Most offices of city not Remote People available. Handling, moving to S2 9. Pests and Rodents L1/L2 Premises IT Infrastructure Primary site not available. S1 10. Bombing / Acts of L3/L4 Premises / IT Infrastructure / Most offices of city not Remote Terrorism Citywide People available. Handling, moving to S2 11. Food Poisoning / L3/L4 Premises / City People Employee shortage S1 Epidemic / Medical wide Emergency 12. Virus Attack / Malicious Codes / Spam L1/L2 IT Systems IT Infrastructure Application level disaster S1 13. Denial of Service L1/L2 IT Systems IT Infrastructure Application level disaster S1 14. Network Penetration / L1/L2 IT Systems IT Infrastructure In worst case scenario, SDC S1 Hacking (Internal/ Infrastructure not available External) DIT, Government of India Page 12

13 15. WAN Link / L1/L2 IT Systems IT Infrastructure One or more premises S1 Communication Failure affected Hardware Failure L1/L2 IT Systems IT Infrastructure SDC critical systems affected S1 / S2 Software failure L1/L2 IT Systems IT Infrastructure Minor outages S1 DIT, Government of India Page 13

14 Chapter 4: Categorisation of Applications Applications at the State Level shall be categorised into criticality ratings so as to map appropriate Recovery points on them. The criticality of each State Department application / data shall be decided by the State, with inputs from the User Department compiled and analysed by the Composite Team after doing a thorough BIA (Business Impact Analysis). For more information on the same including how to conduct a Business Impact Analysis, please refer to the SDC Disaster Recovery Handbook document. DIT, Government of India Page 14

15 Chapter 5: Prevention Strategies / Fault Tolerance For optimum functioning of any State Data Centre, there needs to be redundancy and prevention mechanisms for all the hosted equipments, and the premises as a whole. Having Prevention Strategies in place is always more cost-effective than attempting recovery after the interruption. The aim is to cover as many identified risks as possible, so that the recovery strategy has to work only on the residual risks. Following are some of the steps that are envisaged to be followed at the SDCs as Prevention / Fault Tolerance Strategies: 1. Security Policy Most of the safeguards are closely related to the Information Security Policy and Practices in the State. Adherence to the Information Security Policy, ascertaining preventive safeguards, monitoring of the systems and SLAs are adopted as deterrent controls. Compliance to these Information System policies is required as part of preventive actions to avoid Man-made Disaster occurrence, and further minimize the damage in case of such an occurrence. 2. Adopted Prevention Strategies As part of Risk Assessment to be carried out by the States, mitigation controls for identified risks in place are important to be followed as an important mechanism of preventing a Disaster Declaration scenario disrupting the normal SDC operations. The States are required to refer to their SDC ISMS Risk Assessment Report to be prepared as part of the ISO Certification process at the SDC, and mention the controls in place for all Disaster inducing Generic and IT risks. Broadly, threats that are bound to affect any SDC have been defined below: Fire/ Explosion Earthquake/ Floods Power Outage Air Conditioning Failure Political/Civil Unrest/ Internal Strikes Theft Lightning/ Heavy rains/ Storms Pests Vendor Support Failure DIT, Government of India Page 15

16 Bombing Virus attack Denial of Service Network Penetration/ Internal- External Hacking WAN Link Failure Hardware Failure Software Failure etc The State is encouraged to carry out a Threat Identification process by itself. In case any specific threat applicable for a State has been omitted, the same can be added here by the State. The State is encouraged to undergo The same shall be populated in the following Prevention Strategies Table format in the DR Plan: S No. Threats Probability Impact Preventive Controls The Risk Assessment document, prepared for the Information Security Management System implementation for the SDC at the State maybe referred for assistance in the above activity. DIT, Government of India Page 16

17 Chapter 6: Stakeholder Analysis SDC DR Strategy Document: Version 1.0 In order to successfully drive the DR process from the SDC to the DR Site, multiple entities shall be involved at varied stages, namely Planning and implementation, to perform required actions so that the final DR mechanism is not an isolated technique but a product of a synchronous string of activities performed amongst all identified stakeholders. There are various stakeholders involved in the disaster recovery planning and implementation. Following diagram would depict all the stakeholders being identified as a part of the DR guidelines: DIT, GoI Third Party Audito r (TPA) NIC User Depart ment Stakeholders State Implement ing Agency / State IT Dept Data Centre Operator Composite Team The roles and responsibilities of all the stakeholders is defined at a broad level as being given below: Department of Information Technology: DIT will help the States/UTs for facilitation of DR through the SDC Scheme by provisioning Storage Replication tools, have the required software & Storage Hardware for replication. DIT will also be helping the State Governments with respect to DR by providing policies and Guidelines for DR. National Informatics Centre (NIC): NIC will be providing the space to the respective States in the four NDCs to setup their DR sites. NIC will also be providing Server racks and storage to support the States requirements. Basic manpower & operational support will also be provided by NIC at NDC. (Refer to Annexure A for complete NIC support details) DIT, Government of India Page 17

18 State Implementing Agency: The SIA will be implementing arm for the State and will act as the mediator between the State and NIC. SIA will be ensuring that the State comes up with the DR Plan including the Strategy that the state will be adopting for DR. For States where SIA and State IT Dept are the same, the terms can be used interchangeably. State IT Department: In case the State IT Department differs from the SIA, the Department shall play an advisory role in the functioning of the SIA for DR Planning. The final ownership for any significant DR activity shall rest with the IT Secretary of the State. Composite Team: The composite team will play a more crucial role as they will be providing the State with technological and practical solution to the DR needs of the States. The CT would be actually identifying the DR needs and Strategy and co-coordinating between the various agencies involved for making the DR happen. Data Centre Operator: The DCO will be responsible for taking the actual backup and providing technical resources and controls for implementing and operating the DR Plan and Strategy as framed by the State Government. User Department: The User Department refers to various State / Central Line Departments hosting their applications at the SDCs, through various hosting models available at the respective SDCs. TPA for SDC: TPA will be assisting the CT in enabling the DR process. The roles of the stakeholders shall change over a period of time as the DR will evolve from design to implementation and enter the operations phase. Below mentioned table summarizes the roles and responsibilities of stakeholders involved in the project. Each activity shall have the involvement of multiple stakeholders. However, ownership of the same would differ and the roles of participating stakeholders shall be different, as defined below: A Advice (Advisory / Monitoring Role) The Advisory role for any entity is such where the primary responsibility to execute the activity lies with someone else, and the advising entity is required to provide inputs and advice, whenever referred to by the primary stakeholder E Execute (Primary ownership) Any entity responsible for executing any activity shall be the primary stakeholder for the same, and it is the said entity s responsibility to liaison with other stakeholders for coordination and inputs / advice for the execution & successful closure of the activity. C Coordinate (Performing activities as directed / discussed) DIT, Government of India Page 18

19 DIT, GoI NIC State IT Dept DCO TPA CT User Dept SDC DR Strategy Document: Version 1.0 The coordinating entity shall assist the primary stakeholder(s) (i.e., the activity executing entity) in successful execution of the tagged activity including performing various tasks for the completion as deemed required for the activity. Also, DIT shall provide the Tools for Replication and DR Management, and inform the State on the Service availability at NDC. Note: The Roles and Responsibilities in the below table are indicative, and the State may modify the same as per its own specific requirements, except the R&R mentioned for Central Bodies like DIT and NIC. S. No Activity/ Stakeholders 1 Planning 1.1 Preparing DR Strategy and DR Plan based on DIT & NIC guidelines and States individual studies 1.2 Study of the existing infrastructure at the State SDC 1.3 Categorisation of Applications based on Criticality Factors 1.4 Identification of required Infrastructure at DR Site (Compute, Bandwidth, Manpower, etc) A A E C E C A C E C A C E C A A C C E 1.5 Identification of additional Infrastructure on DR Site, apart from the DR infrastructure provisioned under the scheme 2 Provisioning & Implementation 2.1 Provisioning of Bandwidth for connectivity from SDC to DR site 2.2 Enabling Dept users connectivity to DR Site for infrastructure access & monitoring C E C E E C E C DIT, Government of India Page 19

20 DIT, GoI NIC State IT Dept DCO TPA CT User Dept SDC DR Strategy Document: Version 1.0 S. No Activity/ Stakeholders 2.3 Facilitation of Space, Power, and Cooling in NIC DR facility for installation of equipments (User Dept and Replication infrastructure) 2.4 Facilitation of required infrastructure like space, power for installation of Replication infrastructure in SDC 2.5 Procurement and installation of SAN Storage for consolidation of DR Storage requirements for mapped SDCs in the DR Site 2.6 Responsibility of bringing the application live and required setup from DR site 2.7 Operations & Maintenance (O&M) of infrastructure owned by NIC at the DR site 2.8 O&M of infrastructure owned by State/UD at the DR site 2.9 O&M of the Application level infrastructure at the DR Site 2.10 DR Training, conduction of Mock Drills, and updation in DR Plan E C C A E C C A E C C C C E C C E E C E C C E C A C E C E C E C 2.11 DR Replication SLA Audit A C E C C 2.12 Infrastructure & Operations Tracking from SDC to NDC (Patch Management, Remote Replication cycle management, Storage availability, Reporting, etc) C C E C DIT, Government of India Page 20

21 Chapter 7: Security Analysis during Disaster Recovery While the Disaster Recovery process is underway, the Information Security Guidelines at each State is susceptible to be compromised, depending on the Level of Disaster. It shall be the responsibility of the Crisis Management Team (CMT) by liasioning with the other DR teams formed to ensure the Confidentiality, Integrity, and Availability of data as per its criticality, even during the time of a Disaster. DIT, Government of India Page 21

22 Chapter 8: System Level Disaster Recovery Plan Each User Department system can have an individual DR Plan for scenarios wherein partial Application level DR takes place. The document may contain system level information of all the User Department IT infrastructure hosted at the SDC, the replication schedule, the relevant contact personnel details, and Recovery steps in case of a DR. The State can create a separate document to achieve the same, titled <State Name> System Level Disaster Recovery Plan. Thus, for any addition in Applications to the SDC, the said document can be appended as soon as the hosting for the same goes live at the SDC. Below is an indicative format for the System Level DR Plan. OVERVIEW PRODUCTION SERVER at SDC Location: Server Model: Operating System: CPUs: Memory: Total Disk: System Handle: System Serial #: DNS Entry: IP Address: Other: DR SERVER at NDC Provide details with respect to Production Server APPLICATIONS to be replicated at the DR (Use bold for DR Site) ASSOCIATED SERVERS KEY CONTACTS DIT, Government of India Page 22

23 Hardware Vendor System Owners Database Owner Application Owners Software Vendors Offsite Storage Provide details Provide details Provide details Provide details Provide details Provide details BACKUP STRATEGY secondary site (if any) for Daily Monthly Quarterly Provide details Provide details Provide details SYSTEM DISASTER RECOVERY PROCEDURE Scenario 1 Provide details Total Loss of Data Scenario 2 Provide details Total Loss of Hardware File System as of <date> Filesystem kbytes Used Avail %used Mounted on DIT, Government of India Page 23

24 Minimal file systems to be created and restored from backup: <Provide details> <List> Other critical files to modify Necessary directories to create <Provide details> <Provide details> Critical files to restore <Provide details> Secondary files to restore <Provide details> Other files to restore <Provide details> DIT, Government of India Page 24

25 Chapter 9: Detailed SDC DR Architecture and Design In order to effectively design a recovery plan in the event of a Disaster at SDC, there needs to be a prior understanding of the Network Architecture and overall Design of the SDC. Since it is expected for the State Consultant, CT, and NIC to help the State in creating an optimum DR Plan, the State shall include a detailed SDC DR Architecture, including but not limited to, Network, Application Hardware used and underlying Technologies used for the same, etc. The State may opt for creation of a separate document to achieve this, or integrate the same with the System Level Disaster Recovery Plan for a single holistic view of the SDC in terms of the Architecture and the Technology present therein. DIT, Government of India Page 25

26 Chapter 10: Disaster Recovery Teams Composition For undertaking a DR, all activities are required to be performed by skilled SDC members with specific roles & responsibilities. To streamline the same, the DR activities shall be split into functions for 4 teams. Following are the team names and their indicative compositions. For detailed Team structures and their respective Roles & Responsibilities, kindly refer to the SDC DR Handbook document. 1. Disaster Recovery Planning (DRP) Coordinator: The DRP Coordinator shall be a person with comprehensive decision making powers, and must be a member from the higher State Authority expected to lead the DR activities through the various DR teams. DRP Coordinator State IT Dept Head 2. Crisis Management Team (CMT): The Crisis Management Team shall comprise of Management level personnel who shall analyze the damage at SDC, advise the DRP Coordinator for Disaster Declaration, and initiate the recovery of Operations at the DR Site. Crisis Management Team SIA Head NeGP Project Heads / Nodal Officers Project Manager CT DCO Project Manager CT member DIT, Government of India Page 26

27 3. Damage Assessment Team (DAT): The Damage Assessment Team shall comprise of management, and technical experts who shall assess & report the damage at SDC, and take steps to minimize the extent of the same. Damage Assessment Team Project Manager CT CT member CT member DCO Senior Members Team Leads User Dept Coordinators 4. Operations Recovery Team (ORT): The Operations Recovery Team shall comprise of management and technical experts who shall undertake the recovery operations for SDC at the designated DR Site. Operations Recovery Team Senior CT Member Team Leads DCO Project Manager Selected DCO members User Dept Coordinators CT members Other SIs 5. Help Desk The existing Help Desk at the SDC shall perform the emergency Help Desk operations described in detail in the SDC DR Handbook Document. Relevant training and drills shall be conducted for the Help Desk for coordination among various DR teams. DIT, Government of India Page 27

28 Note: The above is an indicative Team Composition Compilation. The State may opt for changes to the same as per its convenience. However, care should be maintained to ensure the availability and expertise of personnel nominated for the required teams as per their expected roles in the DR Teams. Detailed Templates of these team details are available in the SDC DR Handbook document for the State to fill. DIT, Government of India Page 28

29 Annexure A : SDC DR Services available at the DR Site (NDC) Note: i. All NIC services mentioned below shall be valid for a period of 5 years from date of SDC Operationalization (Date of FAT Completion) or for a period as mutually agreed between the State and NIC in the Memorandum of Understanding (MoU) signed between the same., whichever is later ii. All IT infrastructure support provided by NIC shall be valid for a period of 5 years from the Date of Operationalization (Date of FAT Completion) of the State SDC. iii. All Infrastructure (including support for the same) provided by NIC at the NDCs shall have a quantity capping as mentioned in the below table. In case a State wishes to procure additional Infrastructure, the same can be mutually agreed between the State and NIC. These Infrastructure components shall be provided as per a yearly phasing plan mentioned in the below table, wherever applicable. S No. Category Requirements Action Plan 1 Physical Space Rack Space NIC to provide 20 Racks for Large States each, 15 Racks for Medium States each, and 7 Racks for Small States each, in a phased manner. The phased plan shall be shared with the States. Standard Racks (42U, 5KVA power) have been agreed by NIC to be provisioned for the SDCs. Racks under this category shall include Server racks only. Network, Database, and Storage racks shall be separately provisioned by NIC DIT, Government of India Page 29

30 Need based Seating Space NIC to provision space for 5-10 personnel on a temporary need basis, for User Departments and their associated personnel requiring to work on their IT infrastructure hosted at the NDCs. Power with UPS HVAC Physical Security / Access Control 2 Core Services Hardware, Storage Monitoring & Management NIC to extend all of the above Core Services to SDCs at the respective NDCs. Support for backup, replication & recovery services Monitoring & Reporting 3 IT Infrastructure Network (LAN, Internet, LAN, Internet to be provisioned by NIC. DIT, Government of India Page 30

31 Connectivity to SDC Connectivity between SDC and NDC is required for enabling a channel for Data through NKN) transfer for Replication between SDC and NDC. The responsibility of connectivity between SDC and NDC lies with each State. However, currently NKN project is underway as a pilot in selected States, and in the future during the NKN national roll-out, the SDC-NDC connectivity through NKN can be explored by the States. Funds for the connectivity have already been allocated to the States as part of the SDC Scheme. It is important for the States to consider a reliable Bandwidth source, since periodic Replication shall occur on this line. Internal and Cyber Security (Firewall, IPS, HIPS, etc) Storage Basic perimeter level firewalls to be provided by NIC. Any particular application level security shall be provisioned by individual user departments. An estimated 5000 TB (200 TB for Large States, 150 TB for Medium States, and 80 TB For Small States) shall be required by all States for their DR at all the combined NDCs. The States shall be communicated with their individual phased plans for storage provisioning at the NDCs. Separate Storage arrays as raw storage without any virtualized components shall be provisioned by NIC. DIT, Government of India Page 31

32 Compute Device Monitoring Servers required by the State for Application level Disaster Recovery shall be provisioned by NIC. The number of Servers allocated for each State shall be intimated by DIT. Rack based IP-KVM devices to be provisioned by NIC 4 Manpower Dedicated NIC DR Team at NDC NIC shall position dedicated personnel at the DR Site for SDC DR, as per the following break-up: Delhi NDC - 10 Bhubaneswar NDC 4 Hyderabad NDC 3 Pune NDC 3 Help Desk 24x7 5 Policy, Process and Guidelines Support Broad level DR Strategy and approach DIT and NIC together are already in the process of preparing DR guideline documentation that shall be shared with the States for them to formulate their SDC DR plans. to the State Helping the State in preparing State Specific The State Composite Teams, while preparing the DR Plans for the respective States with the State Consultants, will be assisted by the Central NIC Team in DIT, Government of India Page 32

33 DR Plan formulating the SDC DR Plans, which will help the States in their respective DR activities. Formulating the SDC DR Plans, which will help the States in their respective DR activities DIT, Government of India Page 33

34 Annexure B : Replication Solutions SDC DR Strategy Document: Version 1.0 Replication is the process of sharing information so as to ensure consistency between redundant resources, such as software or hardware components, to improve reliability, faulttolerance, or accessibility. Data Replication is chosen if the same data is stored on multiple storage devices, and computation replication is chosen if the same computing task is executed many times. A computational task is typically replicated in space, i.e. executed on separate devices, or it could be replicated in time, if it is executed repeatedly on a single device. There are primarily four types of standard replication methodologies as described below: Storage Based Replication There are two Storage Replication techniques available in the industry today, as follows: 1. RDBMS based Replication: States/UTs will be having Databases with inbuilt capacity for replication, like Databases using Oracle Data Guard. In such a scenario the requirement of each database will be different and it will be the responsibility of the State/UT to maintain it. NIC will be providing only the required space for hosting. o Database based replication may require installation/configuration licenses of DB o Database based replication solution typically provides support for replicating across storage models from different vendors. o Same type of configuration and same number of liceses is required at the DR site also. o This may need to be procured from the same DB vendor as of the DB licenses of the application. o The licensing methodology is typically dependent on the number of licenses of the DB. It is independent on amount of data that needs to be replicated. o This methodology may entail utilization of server resources for its functioning. DIT, Government of India Page 34

35 o It supports replication in both synchronous as well as asynchronous modes, which can be configured as per the requirements and feasibility of the solution. 2. Appliance Based Replication In appliance based replication, an independent appliance is being installed, which would be utilized for sending and replicating data from main site to remote site. Following are the points to further elaborate the solution pointers: o Appliance based replication requires installation/configuration of some components at servers/ storage array. o Appliance based replication solution typically provides support for replicating across storage models from different vendors. o Appliance based replication software supports IP protocol natively and does not require any external FC-IP conversion equipment. o This capability may not be provided by the Storage vendor natively and may need to be procured from a different vendor. o The licensing methodology is typically based on the amount of data that needs to be replicated. It is typically independent on number of servers that access the data in the attached storage array. o This methodology may entail utilization of server/storage resources for its functioning. Typically, the appliance will also need to be sized appropriately based on the expected workload. o It supports replication in both synchronous as well as asynchronous modes, which can be configured as per the requirements and feasibility of the solution. o This methodology supports different topologies like one to one, one to many. However, the extent of support for these topologies maybe vendor dependent o Certain features and capabilities of appliance based replication may be vendor specific. o This methodology supports multiple type of application with the same solution. DIT, Government of India Page 35

36 In storage based replication, the data is being replicated to the remote site with the help of software being run at the storage itself. Storage is same at SDC and DR: If the storage is same at DR and SDC, the replication between SAN to SAN is comparatively very easy and it would be easy to replicate. Only the licences need to be verified and the cost. This would be the most cost effective model of creating the DR. Storage is not same in SDC and DR: In this case when the store at SDC and DR are not same, in order to a replication between DR and SDC certain modifications have to be made and the SDC and DR need to be enhanced. Some of the enhancement that need to be made such as virtualizing heterogeneous storages at both the ends with a pair of consistent devices or choosing such tools which make different storage interoperable and able to replicate to different make and model of Storage at the DR site Following points would further define the solution: o Storage based replication methodology is independent of the servers being used and doesn t require installation of software on the servers o It will require FC to IP conversion equipment externally, as per the requirement and the replication solution being utilized o It generally requires require identical arrays at both sites for replication of data, unless virtualization capability is being utilized o All major Storage provides this capability along with their storage array, however it needs to be purchased/licensed separately. o The licensing methodology is typically based on the amount of data that needs to be replicated. It is independent on number of servers that access the data in that storage array. o This methodology may entail utilization of storage resources for its functioning. DIT, Government of India Page 36

37 o It supports replication in both synchronous as well as asynchronous modes, which can be configured as per the requirements and feasibility of the solution. o This methodology supports different topologies like one to one, one to many. However, the extent of support for these topologies may be vendor dependent o Certain features and capabilities of storage replication may be vendor/ storage specific. o This methodology supports multiple type of application with the same solution. Host Based Replication The Servers whose data needs to be replicated, act as a host and run the replication software to replicate data across sites. Following points would further elaborate: o Host based replication requires installation of replication solution across all the servers whose data needs to be replicated. This data might be in an external storage array or internal to the servers. o Host based Replication solution typically provides support for replicating across storage models from different vendors. o Host based replication software supports IP protocol natively and does not require any external FC-IP conversion equipment. o This capability may not be provided by the Storage vendor natively and may need to be procured from a different vendor. o The licensing methodology is typically dependent on the number of servers. It is independent on amount of data that needs to be replicated. o This methodology may entail utilization of server resources for its functioning. o It supports replication in both synchronous as well as asynchronous modes, which can be configured as per the requirements and feasibility of the solution. o This methodology supports different topologies like one to one, one to many. However, the extent of support for these topologies maybe vendor dependent o Certain features and capabilities of host based replication may be vendor/ storage specific. DIT, Government of India Page 37

38 o This methodology supports multiple type of application with the same solution. Application Based Replication Application based replication essentially consists of having an application with its own data replication capability, which shall be utilized for replicating data from main site to remote site. Below points would further help in defining the same: o Application based replication may require installation/configuration of some components on the servers. o Application based replication solution typically provides support for replicating across storage models from different vendors. o Application based replication software supports IP protocol natively and does not require any external FC-IP conversion equipment. o This capability may not be provided by the Storage vendor natively and may need to be procured from the application provider. o The licensing methodology is typically dependent on the number of servers. It is independent on amount of data that needs to be replicated. o This methodology may entail utilization of server resources for its functioning. o It supports replication in both synchronous as well as asynchronous modes, which can be configured as per the requirements and feasibility of the solution. o This methodology supports different topologies like one to one, one to many. However, the extent of support for these topologies maybe application vendor dependent o Certain features and capabilities of application based replication may be application specific. The capability of application based solution with respect to data replication is restricted to a specific application only. This means that each application will have its specific replication methodology which will not support any other application. DIT, Government of India Page 38

39 Key Considerations while choosing a Replication Solution There are a number of factors which shall help in understanding the requirements and identifying the appropriate solution. The parameters, as being mentioned below, may vary from application to application or environment to environment and hence, it becomes further important to delve on these and come out with an appropriate solution: Recovery Point Objective / Recovery Time Objective Recovery Point and Time Objectives define the criticality of the data and acceptable level of the application unavailability. This becomes one of the most prominent factors for identifying the appropriate replication methodology. Amount of data The rate of data change would further becomes a parameter which determines the identification of solution, as there may be a requirement of architectural enhancements to be done based on the data change rate and hence, feasibility of the appropriate solution also needs to be examined for the same Number of servers Number of servers may define the choice of replication solution again, as this would be a determination factor in understanding the manageability of the complete environment. Interoperability Choice of replication solution becomes even more difficult and important in very complex environments, involving different type of storage platforms. The replication solution required in such environment should be able to work as an independent platform for replication of data across different heterogeneous storage Cost The choice of technology and solution is also being limited with respect to the cost associated with the solution. There may be a solution, becoming unviable because of the cost of the components involved and licensing required to implement the entire solution Support The choice of solution also needs to be identified in relation to the availability and kind of support available for the same. It becomes important to have a solution which is fully supported by the vendor, as per the requirements of the DR replication technology, so as to meet the overall objectives of uptime of entire solution DIT, Government of India Page 39

40 Type of application The identification of replication solution also gets limited by the kind of the application for which data needs to be replicated. DIT, Government of India Page 40

41 Annexure C : SDC NDC Mapping SDC DR Strategy Document: Version 1.0 The following indicative mapping of DR Site for each SDC at the 4 NDCs (Delhi, Hyderabad, Pune, and Bhubaneswar) has been prepared in consultation with NIC: DIT, Government of India Page 41