Selling Disaster Recovery as a Service
•Download as PPTX, PDF•
2 likes•895 views
This webinar teaches ServerCentral sales partners how to position DRaaS to customers.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to Selling Disaster Recovery as a Service
Similar to Selling Disaster Recovery as a Service (20)
Recently uploaded
Recently uploaded (20)
Selling Disaster Recovery as a Service
- 1. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Disaster Recovery as a Service 23 July 2015
- 2. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com John Macchia Director, Channel jmacchia@servercentral.com +1.312.268.9227 Chris Rechtsteiner Vice President, Marketing chrisr@servercentral.com +1.312.268.9241
- 3. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com The Business Continuity Continuum From Backup to Replication to Disaster Recovery
- 4. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Business Continuity Service Offerings Backup Archive Replication DR / DRaaS
- 5. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Defining DR & DRaaS Disaster Recovery − Disaster Recovery is an area of IT security planning. It focuses on protecting an organization from negative impacts associated with an unplanned event, such as a natural disasters, equipment failures, etc. The objective of DR is a formal DR plan (DRP) that can be followed in an emergency to restore applications and services. This plan is a collection of policies, procedures, and actions that are clearly understood throughout an organization, tested regularly, and quickly executed in the event of a natural or human-induced disaster. Disaster Recovery as a Service − DRaaS takes DR one step further by offloading failover testing and execution of event mitigation onto ServerCentral. In a DRaaS environment, the replication of your customer’s virtual infrastructure takes place in our data centers. The DRP policies, procedures, and actions are clearly defined by both your customer and ServerCentral. Our team conducts regular testing of failovers scenarios and, in the event of an actual emergency, we can perform your failover as well. The entire DRaaS service is wrapped in a predefined Service Level Agreement (SLA) specifically written to achieve your customer’s business’s operating objectives. Source: http://www.servercentral.com/what-is-disaster-recovery-as-a-service/
- 6. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Recovery Time & Recovery Point Recovery Time Objective (RTO) − The targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity. Recovery Point Objective (RPO) − The amount of data at risk. It's determined by the amount of time between data protection events and reflects the amount of data that potentially could be lost during a disaster recovery. The metric is an indication of the amount of data at risk of being lost.
- 7. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Disaster Recovery as a Service How does this work?
- 8. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com The Process Discovery − Current status of your customer’s DR strategy? − RTOs / RPOs for each application? − Recovery prioritizations for each application? − Compute, memory, storage, network footprint for each application? − Minimum viable infrastructure for recovery for each application? − End-users connections to these applications? − Security and compliance requirements? (PCI, HIPAA, etc.) − What is an event?
- 9. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Note: All Apps Are Not Created Equal Communications eCommerce ERP CRM Files / Apps Network Dev Stack Access Days : Hours : Minutes : Seconds
- 10. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com The Process Discovery − Current status of your customer’s DR strategy? − RTOs / RPOs for each application? − Recovery prioritizations for each application? − Compute, memory, storage, network footprint for each application? − Minimum viable infrastructure for recovery for each application? − End-users connections to these applications? − Security and compliance requirements? (PCI, HIPAA, etc.) − What is an event? Planning − ServerCentral develops a proposed solution to address requirements including backup, replication and DRaaS (where applicable). Validation − ServerCentral meets with you and your stakeholders to present the proposed solution and project timelines.
- 11. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com The Process Development − ServerCentral solution architects begin development of the required business continuity infrastructure including defining event mitigation processes, network elements, security, compute, memory and storage resources, etc. Testing & Deployment − Your business continuity infrastructure is turned on, tested, and certified for production. During this phase our experts are working directly with you to make sure all objectives have been met. Management − ServerCentral provides ongoing management and administration of all core business continuity elements including network, security, compute, storage, failover testing and event mitigation.
- 12. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com The Result Your Runbook − Custom configurations, policies and procedures that detail every step in the testing and event mitigation processes.
- 13. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Event Declaration
- 14. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Event Declaration & Mitigation Event Declaration − Alert triggers automatic declaration − Manual declaration Mitigation / Failover − The failover is triggered, DR compute resources are engaged and IP spaces are re-assigned − 100% within the parameters defined in your custom Runbook Return to Production − When (if?) appropriate, a custom procedure, as defined in your Runbook, will be implemented
- 15. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Technology & Infrastructure
- 16. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com The Infrastructure Primary Data Center Chicago, IL Multi-Site Replication San Jose, Ashburn, Tokyo Secondary Data Center Ashburn, VA MPLS 10Gbe IPSEC Network Stack VMs Databases / Storage Internet IP: 1.1.1.1 IP: 1.1.1.1 IP: 10.1.1.1 Shared Cloud Private Cloud Dedicated Infrastructure
- 17. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Non-Virtualized Environments
- 18. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Pricing Components Virtual Machines − Number of VMs supported with DRaaS − Cost type: MRC Nodes − Compute, memory, storage and bandwidth requirements & type − Cost type: MRC Management − We can manage everything or nothing − Cost type: MRC or event based Event Declarations & Recoveries − Level of support required in support of the event declaration and subsequent recovery − Cost type: MRC or event based Testing − Frequency & depth of tests − Cost type: MRC or event based
- 19. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Why DR & Business Continuity? 50% | 50% | 60% | 70%
- 20. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Why DR & Business Continuity? Process and Solutions are Non-Existent − If they do exist, they’re likely thin RTOs and RPOs are Not Likely Defined − Simple answers to simple questions Clear, Logical Reasons for Better − This is the easy part Gateway Solution − Tremendous way to gain trust and expand existing relationships
- 21. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Starting the DRaaS Conversation What are they doing today? Which apps, data, services are being backed up? Which services have priority SLAs, RTOs or RPOs? Are there compliance requirements for different apps? Which hypervisor platform are they running (e.g. VMware) How are they connected to the internet? (e.g. 10Mbps, etc.)
- 22. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Why ServerCentral? Service & Support − There are experts here, ready and willing to assist around the clock Quality of our Infrastructure − Unmatched speed and reliability on compute, storage, security & network Networking − The ability to solve the connectivity issues for continuous service Clear Paths for Evolution − Moving from backup to replication to DR at your customer’s pace Recovery − Should an event occur, we have the facilities, resources and expertise to get customers back up and running with custom-definable SLAs
- 23. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Get Started! go.servercentral.com/partners/draas
- 24. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Questions?
- 25. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Thank you!
- 26. ServerCentral | 111 W . Jackson Blvd., Suite 1600 Chicago, IL 60604 | +1 312.829.1111 | www.servercentral.com Disaster Recovery as a Service 23 July 2015
Editor's Notes
- Good morning / afternoon everyone! Thank you joining us today. We’re really excited about our Business Continuity solutions - and especially our Disaster Recovery as a Service offering. Infrastructure and application uptime are values that we work to maximize for our customers every day. This is why DRaaS is so exciting for us. Well, that and the fact that we’re all infrastructure geeks. Before we get started please know that our hope is that in sharing this information with you, you will be able to clearly see how we’re approaching the critical requirement of disaster recovery and how we can help your customers address these requirements, too. If you have any questions, please ask them! We will collect the questions and answer as many of then as we can at the end of the webinar. We will also add these questions and answers to our partner portal so you can reference them at your convenience. With all of that being said, let’s get started.
- My name is <FIRST LAST>. I’m the / an <TITLE> for ServerCentral. My role here, as you know, is to support you and your customers. You already know this, but I encourage you to remember that I am your advocate within ServerCentral. Anything you need on a technical, business or strategic issue, please feel free to contact me and I’ll be sure it gets done. With me today I also have: <FIRST LAST>, our <TITLE>. <FIRST> has joined us today to <SPECIFIC REASON FOR BEING ON THE CALL> Our contact information is on this slide for a reason. Please do not hesitate to use it if you have any questions at all. At this time I’m going to hand the presentation over to Chris. Chris…
- Thank you John – and thank you, again, for joining us today. Where do we begin? Let’s begin with Business Continuity. When we speak about Business Continuity we’re really speaking about a continuum that begins with backup and ends with turnkey disaster recovery services. The reason we view it in this way is that all applications (and all businesses) have very different needs. Successful business continuity isn’t one answer to one question. It’s multiple answers to multiple questions – all aligned specifically in support of your customer’s unique business requirements. Is this the only way to view Business Continuity? No, it isn’t. We don’t expect it to be. However, we do have a tremendous amount of experience working with companies like Basecamp, New Relic, Outbrain, and many others on a daily basis to develop the best possible solutions to meet their needs – and the solutions to these requirements will consistently fall along one (or more) steps of this continuum.
- Our business continuity service offerings are comprised of four (4) discrete solution sets that can be applied to applications individually (or collectively) to meet your customer’s specific requirements. Backup is the most basic – a simple and straightforward way to copy and later retrieve applications, files and data from a location outside of your customer’s production environments. Archive is simply the cold storage of backups and other data that won’t need to be recovered to maintain production. Archival is typically utilized for data with long-term security, legal or compliance retention requirements. Replication – the frequent (or near real-time) copying of applications and data from one location to another so that all systems share the same level of information. The key here are the terms frequent or near real-time. The expediency of the replication process is a key element of our DRaaS offering – as you will see. It’s important to recognize these various offerings before talking about Disaster Recovery as they often play a critical in a complete DR solution environment. Finally, what we’re here to talk about today, Disaster Recovery.
- When we say Disaster Recovery, what are we talking about? We define Disaster Recovery as an area of IT security planning. DR focuses on protecting an organization from negative impacts associated with an unplanned event, such as a natural disasters, equipment failures, etc. The objective of DR is a formal DR Plan (DRP) that can be followed in an emergency to restore applications and services. This plan is a collection of policies, procedures, and actions that are clearly understood throughout an organization, tested regularly, and quickly executed in the event of a disaster – whether it’s a natural disaster or human-induced disaster. This last part, human-induced disaster, is an important point to remember as we continue. Disaster Recovery as a Service takes DR one step further by offloading failover testing and execution of event mitigation onto ServerCentral. In a DRaaS environment, the replication of your virtual or physical infrastructure takes place in our data centers. The DRP policies, procedures, and actions are clearly defined by both <COMPANY> and ServerCentral. Our team conducts regular testing of failovers scenarios and, in the event of an actual emergency, we perform your failover as well. The entire DRaaS service is wrapped in a predefined Service Level Agreement (SLA) specifically written to achieve <COMPANY’S> operating objectives. Are there any questions?
- While we’re in definition mode, I’d like to present two more definitions and then we’re off and running. Hopefully you are familiar with RTO and RPO – Recovery Time Objectives and Recovery Point Objectives. If you aren’t – these are critical elements you should become familiar with sooner rather than later. Recovery Time Objectives or RTOs are the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity. Recovery Point Objectives or RPOs are the amount of data at risk. It's determined by the amount of time between data protection events and reflects the amount of data that potentially could be lost during a disaster recovery. The metric is an indication of the amount of data at risk of being lost. These are critical values that we’re going to refer to throughout the discussion, so please keep these definitions in mind. OK – let me stop for a minute and say thank you. The past two slides may seem a bit rudimentary. I’ve presented plain level definitions and taken a dive into this painstaking level of detail for a reason. Thank you for staying with me here. It’s going to make a lot of sense as we begin walking through the ServerCentral DRaaS process.
- How does ServerCentral DR as a Service work? Let’s take a look.
- Disaster Recovery is as much about process as it is about technology. We begin all DR as a Service relationships with a very clearly defined process. The first step in this process is Discovery. During discovery we’re going to: Identify the current status of your customer’s DR strategy. Set RTOs / RPOs for each application Set recovery prioritizations for each application. A recovery prioritization is the order in which each application will be brought back online. Identify Compute, memory, storage, network footprint for each application Define minimum viable infrastructure for recovery for each application. In many cases you won’t need 100% coverage for a non-critical application when in a disaster state. Map exactly how end-users connect to these applications. Verify security and compliance requirements so that you remain inline should a disaster event occur. Define the characteristics of an event – specifically what needs to happen in order for an event to be declared and a failover action to be executed.
- Within your customer’s infrastructure an important distinction to make is which applications have which RTOs / RPOs. What we’re asking is, “How critical are these applications, really?” We uncover this information during the discovery process, at this granular level, because applications and processes are likely to have significantly different requirements than one another. Some applications will need to be up and running instantaneously should a disaster event occur. Other applications may not be required for days (or even weeks). Once each application in question has been assigned RTO/RPO values within the discovery process, we can really begin to identify the key requirements for meeting your customer’s business continuity objectives. Why do we put so much emphasis on this part of the process? It’s simple, really. Some applications are very easy to prepare for and manage in the case of a disaster. Anything Virtualized / Clustered / Software with support for failure scenarios – applications like email, for example – are easy to prepare for. These types of applications require far less resources and planning to provide continued service. However, other applications are far more difficult to prepare for and manage. Old, end-of-life software and homegrown or legacy apps not coded for redundancy are prime examples of difficult to prepare for and manage applications. Physical servers with older OS’s which may have certain BIOS requirements, RAM requirements, specific drivers for older hard drive interfaces (ATA or SCSI ) may not be easily or readily available. The point of discussing this in detail isn’t to create FUD. We simply want to be 100% sure your customers understand all of the steps we’re going through to deliver you a business continuity solution that meets their needs. We want to leave no stone unturned.
- After Discovery is complete we’ll begin Planning. Planning is a ServerCentral-focused step in the process. During this step our solution architects, network engineers, virtualization experts, storage experts, DC Ops managers, provisioning team and professional services managers work together to develop a solution that meets the requirements identified during the Discovery phase. When the Planning is complete, and we have what we believe to be a sound solution for your customer’s requirements, we’ll meet with you and your customer’s stakeholders to present the proposed solution and discuss project timelines. The Validation step in the process is where the most give and take occurs. This is where scope will change, answers to questions identified in Discovery will change, etc. This is by far the most fluid part of the process … but it’s also the most important. At this point your customers will see, first hand, how we’ve taken their requirements, applied our experience (and technology), and arrived at what we believe is the best possible solution for them. Sometimes our answer is met with a resounding, “Yes! That’s it!”. Other times our answer is met with, “Well, this is a good start but it’s too expensive.” or, “This is really awesome, but it’s, too expansive. We’re just not ready for this much.” Any answer your customer provides at this point is fine. The point of validation is to get the solution “just right” so that everyone is happy, comfortable and all needs are accounted for.
- After Validation we’ll begin with the Development of the solution’s infrastructure. This will include event mitigation processes, network elements, security / compliance requirements, compute / memory / storage resources, etc. While in Development there will be a lot of back and forth between ServerCentral and your customer - but the interactions are likely to be more tactical than strategic in nature. From Development we move on to Testing & Deployment. This phase is pretty self explanatory. Testing encompasses verifying the infrastructure will perform as it was architected should a disaster event be declared. Deployment encompasses a true test run via a test failover to be sure the infrastructure is set and all applications perform as intended in the failover state. The final step of the process is Management. At this point the solution is deployed and we’re providing ongoing management and administration of all core business continuity elements including network, security, compute, storage, failover testing and event mitigation. We’ll talk more about event mitigation in a bit, so please hold this thought.
- What is the result of all of this “process”? Each ServerCentral DRaaS customer receives their own unique Runbook that details the specific configurations and steps associated with their DR as a Service environment. This Runbook is a living, breathing document that is followed by all ServerCentral operations teams in support of your customer. This is the law, if you will, relative to how we will support your customer and deliver their DR as a Service solution. Periodic reviews of the Runbook are also scheduled to be sure that the changing elements of your customer’s business and infrastructure continue to be met.
- OK. Let’s now take a look at how an event declaration is managed.
- The most important question – What happens when an event is declared? We’ll walk through this process so you have a detailed understanding of exactly what happens. First and foremost – a disaster event declaration is exactly why we have custom Runbooks as everything that takes place will be in accordance with your customer’s specific Runbook. How is an event is declared? An Event Declaration can take place either automatically or manually. An automatic declaration is a declaration triggered by a system alert. This alert can be anything your customers want defined as a critical occurrence that requires their application(s) to failover. These alerts are defined during Discovery and setup during Development. These alerts are noted in their Runbook. A manual declaration is exactly that – a manual request for failover when conditions exist that they feel meet the need to utilize DR infrastructure. A manual declaration is triggered by a phone call or a trouble ticket submitted to our ticketing system. Once the event declaration has occurred it is time to execute the failover. The failover begins with a spin-up of the DR compute resources. These resources may already be on or they may need to be turned on with the declaration. This is a decision point for your customers in terms of the recovery time required for each application – and the cost associated with those DR resources. This information is also defined in your Runbook. Again, please note that not all applications have to be defined in the same way. The availability of these compute resources can vary on an application by application basis if needed. Once the compute resources are spun-up and verified to be operational, your customer’s IP space will be re-assigned to the DR infrastructure. This is a critical step because it will keep all of your end-users inline with the application. At this point your customer’s applications are online and your end-users are operational. Should it have been identified and defined in the Discovery and Validation phases, we may be involved in helping them understand the root cause of the event. We may not. This is where your specific needs and requirements are going to play a major part in determining exactly what role(s) ServerCentral takes. We can be as involved or uninvolved as your customer likes. It really is a sliding scale. The final step in the disaster recovery process is a Return to Production. This is, without a doubt, the most complex part of the entire process. In order to meet your customer’s requirements, unique processes will be defined within their Runbook. This may include using the “former” production environment for DR now that it has failed over, or it may include an application by application reverse migration to the old production equipment. There isn’t one answer here, so we will work with your customer to discuss the benefits, challenges and risks associated with each potential decision on an application by applications basis. Once this is defined, it will represent the final elements of their Runbook.
- Now that we have the process defined, let’s take a quick look at the technologies underlying the process.
- The infrastructure under our DRaaS solutions is designed to provide near real-time failover should an event occur. However, there are some critical success factors to highlight. You’ll notice in this sample reference architecture that there are identical IP spaces between the two locations. This is a critical element as it is the foundation upon which the near real-time failover can occur. By setting up the network environment in this way, we are able to quickly migrate your customer’s IP addresses from the primary center to the secondary center in the event of an emergency. This sounds trivial, and it is if you plan properly, but it is really important. This process removes one of the hardest and error-prone parts of DR, redirecting applications and end users to the new location. Without this step the risk of a prolonged outage is significantly increased while DNS values are reset and propagated. What does this really mean? This means your customer’s end-users won’t see prolonged outages should an event occur because they are unable to get to the application(s). With ServerCentral, your customer’s IP’s simply stay the same. This is a very common problem with other DRaaS solutions - one that ServerCentral uniquely solves. Moving past the network elements, you’ll notice we have three different flavors of replication infrastructure is deployed the secondary data center. There are multiple ways to deploy this failover infrastructure. We can make available Enterprise Cloud resource pools, Private Cloud resource pools or dedicated physical infrastructure – whatever is most appropriate for your customer’s applications. This decision will fully depend upon their need for coverage – and their budget. This is a really important distinction, too - the ability to make these failover infrastructure decisions on an application by application basis. For instance, your customers may have applications that require 100% coverage should an event occur. For these applications they’ll want to have failover resources available that are equal to their production environment. They may have other applications that can get by with significantly less than 100% coverage during an event. In these cases, as we noted earlier in the discussion, a minimum viable infrastructure that is “just enough” to keep those applications running, may suffice. These are the decisions that are made during the Discovery phase of the process so that we are sure your customer’s RTO / RPO objectives are met and your business continues operation. <CLICK> Once the infrastructure is set we can layer any number of technology solutions into the equation. If it’s a simple backup requirement, or a replication requirement with RTO/RPOs measured in hours, we will work with Veeam. This is a cost effective way to address these requirements. Should your customer require near real-time RTO/RPOs, we’ll work with Zerto. In both cases we’ll prepare whatever recovery compute infrastructure is required – whether it needs to support VMware or Hyper-V or something completely unique to your customer. This, right here, is the true value of ServerCentral – we specialize in delivering exactly what is right for your customer.
- One question that typically arises at this point in these discussions is, “What about non-virtualized environments?” There are a number of options for us to pursue in setting up a DR environment for non-virtualized environments. These solutions are dependent upon some very specific configuration information including network, compute, memory and storage usage (similar to virtualized environments) - as well as the acceptable timeframe between data snapshots. The replication solutions available for non-virtualized environments are based upon snapshot technologies (either independent apps or in-SAN replication capabilities), so we’re talking about completely different RTO and RPO windows when we’re talking about non-virtualized environments. In order to provide a detailed solution for a non-virtualized environment, we'll need to have a conversation that addresses a handful of unique discovery questions so that a disaster event for your application(s) can be mitigated within your desired timeframe. The main difference between the DR and DRaaS solutions is that in an virtualized environment we can work within the IO stream and do near real-time replication. This foundation permits the delivery of the DRaaS solution. In a non-virtualized environment we’re working with snapshot-based solutions that elongate RTO / RPO windows and have a much heavier infrastructure requirement (due to the size of the snapshot data on top of production data). Again, this is something that can absolutely be done, it’s just part of a larger, more detailed conversation that we can have after we finish this one! Before we move on, one quick question. What percentage of our infrastructure is non-virtualized today? Which application(s) are not virtualized? Thank you!
- The question I know you’re ready to have answered … how much does this cost? As I’ve mentioned in our conversation, there are a number of variables that will determine the cost of a DRaaS solution. These variables are completely within your control and are based upon the nature of the configurations and support you require. That being said, let’s look at the individual cost components. The initial cost component is the the number of Virtual Machines you’re looking to protect. These are priced on per VM per month basis. The second cost component is the number of nodes (or amount of DR compute and storage) necessary to support your recovery environment. This is also priced on a per month basis and will vary based upon the state of the compute resources. Compute resources at rest will be less expensive than fully operational (powered on and waiting) compute resources. Storage resources will be based upon the total amount of data that is being replicated across all applications. Next is Management. We can manage as little or as much of the entire DR environment as you like. Obviously the more we’re responsible for, the more it’s going to cost. The benefit here? We can and will work with you to find the perfect balance to meet your needs. Testing. In Discovery and Validation we’ll define the number of tests and their frequency. This can be based on an MRC or a per-event basis. Finally Event Declarations and Recoveries. These, too, can be based upon an MRC or on a per-event basis. In order to provide you with an ABSOLUTE cost, we’d like to walk through the Discovery process with you and your team. Is that something you’d be interested in further exploring?
- There are hundreds (if not thousands) of pieces of research out there on Disaster Recovery and Business Continuity. Rather than bury you with endless facts and figures, let’s look at four key data points that will serve as the foundation for your engagement with your customers. 50%. Pick your research source. It doesn’t matter which one you select. Whenever research is performed it returns a simple, 50% value. More than half of all businesses maintain backups of their data onsite. The good news? They’re backing up their data and understand the value of being able to address a critical event. The bad news? They’re backing up to the same physical location. While this will work to support their business in the case of a technological failure, it will not work to support the business in the event of a power failure or a natural disaster. Think about this for a minute. Over half of all businesses would be offline, without access to critical data and systems, if something as simple as the power goes out. Yes – there is a LOT of opportunity here. While we’re talking about 50% of businesses, let’s also note the fact that more than half of businesses also do not know the exact cost of app downtime. Again – pick your research source. It doesn’t matter which one you select. This is simply a value the most organizations don’t know … and don’t know how to calculate. This, alone, makes having a DR strategy in place a justifiable expense. It gets better, or worse – depending upon which way you’re looking at it. Over 60% of businesses do not have a formal DR strategy. Simply put, should an event occur that knocks a business offline, there is a 60% chance they won’t know what to do or have any formal plans to continue operation of any applications. Amazing, isn’t it? Finally we ramps up to 70%. This is a conservative estimate – but 70% of disaster events are caused by human error. That’s right! 7 out of 10 times the sky falls on someone’s IT infrastructure and applications it is caused because of human error. The importance of BC/DR and DRaaS solutions isn’t an insurance policy against natural disasters … it’s a strategic infrastructure asset that guards against the day-to-day errors that occur in managing increasingly complex technologies in hyper-competitive business environments.
- When you’re talking to your customers, we ask that you keep these four (4) things in mind: First – It is very unlikely that processes and solutions exist to support their business in the event of a physical or technological disaster. If there are processes and solutions in place, they’re likely thin. As you saw on the previous slide, over 50% of companies that backup apps and data do so to the same location as their production environments. This isn’t a scare tactic. Rather, this is a tremendous way for you to help educate your customers on the risks associated with their current infrastructure. Second – It is very unlikely that there are RTOs or RPOs. These are fantastic conversations to have. Simple questions such as, “How long can you live without email?” or “How long can you inventory management system be down before it causes problems for your business?” can lead to very valuable and insightful conversations. You’ll be surprised at their answers, too. Third – There really are clear and logical reasons for better backup, replication and DR solutions. The cost of doing nothing is way too high and the completeness of the business continuity continuum means there are solutions to fit any and every budget and technological requirements. Fourth – Business Continuity is a gateway solution. These are outstanding solutions that lead directly into larger, more strategic conversations around infrastructure, network architecture, security, compliance and much more. You’re walking into a highly valuable conversation and setting a tone that will provide you with significant competitive differentiation, too.
- With all of that being said, here are a half-dozen simple questions you can use to start the conversation with your customers. The key to asking these questions is identifying the “I don’t know” answers. The minute you hear “I don’t know” or “we don’t have an answer” or “we aren’t virtualized” you have a golden opportunity to add significant value to your customer’s business. Also remember that you have the entire ServerCentral team here behind you waiting to help you through this process.
- There are over 100 reasons why companies choose ServerCentral as their IT infrastructure partner – and those people live and breathe infrastructure so your customer’s can focus on their business and their applications. However, that’s a pretty fluffy statement – even coming from a marketing guy. For the real reasons why companies select ServerCentral we asked our customers. Here’s what they had to say. “We’re not dealing with customer service reps. We’re dealing with network engineers, architects and system administrators. You can’t put a price on that.” “We never have to worry about our infrastructure. It’s always going to be online. We were never able to say that before we came to ServerCentral.” “How many service providers have built and manage their own IP network? Whenever there is a network question, ServerCentral has the answer – and much more.” “It’s easy to move applications from backup to replication to DRaaS as requirements change – and to do so at our pace.” “Whatever I need, I know ServerCentral has it in the data center and ready to go – whenever I need it.”
- There is no time like the present to get started. You can visit us at go.servercentral.com/partners/draas to access resources and a copy of this presentation. Additionally, we’ve put a Q&A app on the site where you can submit any additional questions you have regarding BD/DR and DRaaS solutions.
- That’s it! We are finished! At this time we can open it up to questions. <TRANSITION BACK TO JOHN> On behalf of everyone at ServerCentral, we’d like to thank you for your time today. We really appreciate your interest in our DRaaS solutions and hope we have been able to answer all of your questions. If there is anything else we can answer, additional insight we can provide, etc. please do not hesitate to contact me at your convenience. Thank you!
- Thank you!