SAP HANA is an In-memory db and columnar too. So whenever
you plan for a HANA Landscape you need to think DR for business continuity. As
a best practice your DR system will normally be an exact clone of your
production system. This simply means 2x or 3x your production if your QUAL is
also of the same size- which it is in many cases. While the rest of the big
folks have been focused on deploying SAP HANA as another technical upgrade or
migration we have been focusing on the exact opposite side of this trend. Our
focus is business benefits, business excellence and TCO, i.e. how to get the
best quality at the lowest cost for our customers. We call this the IQDCT
process. Increase Quality, Decrease Costs and Decrease Time
in HANA migration- all in one single step. Learnt it from Sony in their quest
for global excellence when their motto used to be ‘Double the Quality and Half the price every two years’. Our
process does tend to save 40% at the initial cost and then approximately the
same annually for the life of your SAP HANA system. We have exceeded this 40%
each of the 7 times having used this process with global marquee SAP HANA migrations
and saved millions of $’s for our proactive customers.
During this search for IQDCT excellence we rapidly realized
that there is another point where there is a clear opportunity to increase
quality and decrease costs at the same time. That is your DR, and DR including
SAP and SAP HANA DR where this blog is focused.
In SAP HANA DR is no small matter. It is critical. However
think of it like this. When you plan for a HANA Production box most companies
normally plan for a fixed growth factor ranging from 10 to 30% per annum. As an
example let’s use our recent BW customer with 1.2 TB of uncompressed legacy
Oracle database in their BW production system. For a HANA system this will
convert to a 600GB of HANA for their production system. Normally a customer
will install more than what they need today, i.e. future growth. The customer
predicted a 30% growth factor per annum for our calculations. Thus, for a 4-5
year plan both SAP and we ended up recommending 3 x 512 GB scale-out servers
for their production environment – which is a 1.5TB HANA Production box. If all
goes according to plan they may exceed this in 3 years as they may have some
acquisitions along the way in 2015-16, which the scale-out design should easily
be able to accommodate.
Now here is the key consideration for DR. If you follow a
traditional package you would put your DR as an exact copy of your production
in another data center at least 40 miles away but preferably more than 150
miles away if you follow recommended DR geo-location planning. You DR is an
insurance policy you hope to never use but it is still an essential one, all
the more so in a SAP HANA In Memory environment.
Our customer is based on the East Coast of the US so they
had one of two options. Option 1 was to place a bare-metal production clone in Toronto
or Washington DC. Our recommendation to them was to put their DR in the cloud
with a 3 point governance check-list. [1]
world-class Cloud partner, who has a [2] proven reputation for cloud with a
Gartner magic quadrant positioning, and [3] is SAP HANA certified for their
service offerings. We know from our experience that there are no HANA HW
manufacturers that make world class components representing every component that
go into a HANA Chassis. See my two blog’s on TDI vs appliance (One
/ Two
) for a little more detail on global excellence with TDI. When
we ran all these three criteria’s against various providers we found one of our
partners to be sitting right at the sweet spot for meeting this SAP HANA business
need – Sungard AS.
They are a world-class Cloud service partner thus meet
criteria 1, are the leaders in the Gartner Leaders magic quadrant validated by Gartner
thus qualify for criteria 2, and are SAP and SAP HANA certified with certified
SAP HANA certified data centers in North America fulfilling criteria 3.
So having established this provider let’s get into the
basics of planning a hybrid SAP HANA environment.
Figure 1: Original Oracle System Landscape
The diagram above is an actual customer SAP BW Landscape. It
consists of the 3 system Production Pipeline and the 2 system Projects
pipeline. In addition it has a sandbox and a training environment and this
customer also has a 4 blade BW Accelerator with 60GB of capacity. The
Production pipe is where the primary enterprise operations are run and the
anchor for all the business applications. The Projects Pipe is where large
projects can run in parallel without disrupting the prime production flows with
all the developments, enhancements and changes that take place in a typical
projects landscape. Just as an example a project could be an upgrade or a new
CRM implementation that needs deployment without disturbing the main production
pipe.
So here is some of the System landscape decisions that
proactive stakeholders undertake:-
- PROD: A lot of customers prefer to keep their production system on premise, i.e. behind a secure firewall of their own. A few have moved their PROD into a private Cloud environment. Some are even bringing the production back from the cloud to an on-premise infrastructure landscape. In our above case this customer has 1.2 TB of legacy data so will go-live with around 600GB of HANA while sitting on a 1.5 TB HANA On-Premise box (to cater for a 3-5 year growth)
- DR: Let’s start with the DR as one migrates to HANA. This instance is currently mandatory and there are various ways to skin this cat but two things that remain constant is that – (i) this is insurance for business continuity in case a catastrophic event brings down your primary PROD environment, (ii) it has to be an exact clone of PROD in all aspects of current use. In DR customers have one of two alternatives, and (iii) the customer will start with only 600 GB of data.
- Pure Traditional: In a super traditional HANA Appliance modeled environment each of the Sandbox, DEV, QUAL, TRAIN, P-DEV and P-QUAL would each be a HANA box. This is not only complex but increases the initial and support costs substantially. The above systems in a traditional plan would be replaced with SAP HANA appliances 1:1. This is how it would work mostly in a SAP HANA Appliances model today. Figure 2 represents The No-Brainer HANA Landscape 1. This is how most SI partners may recommend a HANA landscape on a 1:1 system copy to end up with approximately 7.28TB of HANA. Note: BW Accelerator has been sunset in the migration plan. 7 Box On Premise model
Figure 2: NO-Brainer HANA
- Level 1: DR in the Cloud: As step 1 plan to get your SAP HANA DR into the Cloud on a run license, i.e. pay only for what you use. In our above case only 600GB to start with. This would become a pay as you grow model. Low Brainer HANA DR in the Cloud Option. Figure 3 is our level 1 landscape solution recommendation- the bare minimum level of consideration. Note: DR is now a 0.600 GB of DR based on current consumption. 6 Box on Premise and 1 in Cloud model
Figure 3: LOW-Brainer
Cloud DR 4 HANA
- Level 2: DR + Non-PROD in the Cloud: After the HANA DR was decided to be in the Cloud we reviewed the possibility of taking all the non-production systems to the cloud. Get a SAP HANA Cloud DR environment and subscribe to a run license, i.e. pay only for what you use. In our above case only 600GB to start with. This would become a pay as you grow model. MEDUIM Brainer HANA DR+ Non-Production in the Cloud Option. Figure 4 is our level 2 recommended landscape solution- as additional cloud consideration. Note: No change in overall size as yet. Note 2: Some customers also consider taking their Production to Cloud at this point of discussion. For our examples we leave that as bare metal. 1 Box on Premise and 6 in cloud model
Figure 4: DR +
Non-Prod HANA Cloud
- Level 3: DR + Non-PROD in TDI: TDI allows data-centers and customers to build a custom SAP environment on SAP certified platform’s, read TDI for more details. What this allows us to do is take two ideas to the top of an optimized system landscape for HANA.
- Option 1- Multi-Tenancy: Post SP 9 HANA allows multi tenancy containers in a single HANA box. SP 9 mixed with TDI allows customers to take their QUAL, DEV and SBx into a single cloud environment. This now consolidates all these environments into a single ‘Multi-Tenant’. See brown box on the Production Pipeline as the single 1TB box to start with. Now suddenly PROD is a 1.5 TB On Premise. DR is a 600 GB Start, QA now becomes a 600GB Start and DEV and Sandbox all come down to a start size and not a future potential size. Think Cloud consumption model when planning for this design. This is a pay as you grow model. HIGH Brainer HANA DR+ Non-Production Multi-Tenancy in the Cloud Option. Note: Production has dropped from 5.2 TB down to 3.5 TB Figure 5 is our level 3 recommended landscape solution- as pre-final cloud consideration. 1 Box on Premise 3 on cloud model
- Option 2- Virtual: Think Virtual especially for the Projects landscape. Very few companies need a 24x7x365 Projects landscape. This is an environment that is mostly used for large projects and then sits idle till the next project. Our recommendation is to lease a cloud SAP HANA environment and spin the virtual environment on demand. Post SP 9 and multi tenancy containers we can now place P-Dev and P-Qual a single HANA virtual box. This would become a projects landscape on demand environment with 750 GB to start with. See brown box on the Production Pipeline as the single 1TB box to start with. Think On-Demand Cloud consumption model for this design. . HIGHEST Brainer HANA DR+ Non-Production Multi-Tenancy + Projects on Cloud VM’s in the Cloud Option. recommended landscape solution- as pre-final cloud consideration. 1 Box on Premise 2 on cloud + 1 VM in the Cloud ( for Project Systems)
Figure 5: Optimized
HANA Cloud Landscape
And remember this is just the start of an optimization process. If you follow this you have already saved over 40% in your HANA TCO simply by planning to do it right the first time and every time
PS: A lot of customers have started taking their HANA PROD to Cloud too. It then simply becomes 3 boxes on cloud (with PRD on cloud too) and 1 VM in the Cloud (for Projet Systems)
