S/4: HANA no longer a matter of if, but rather how and when - strongercase for TDI and VMware

Over the last 6 months I've observed a significant evolution in my conversations with customers in regards to HANA adoption.

More agree that the HANA discussion is no longer a matter of "if they will adopt HANA" but rather a matter of how and when. And SAP's statement of direction with the announcement of S/4 HANA is definitely contributing to this change of discussion.

And when talking about the how and when, one interesting factor is the weight the experiences of the early adopters already start to have on the considerations of the new adopters.

There were 3 particular customer engagements that really got me on to write this blog, as they represented 3 very different stages of HANA adoption. And all these 3 experiences highlighted 3 things I've been writing about for more than a year now: the impact of start-up cost, operations cost and change cost. As usual my focus is on the infrastructure impact of HANA in customer datacenters.

In summary my findings were:

1   - with a customer now planning the introduction of HANA in their datacenter portfolio, one of their biggest concerns was the risk and cost introduced by having to change their standards in datacenter architecture and operational processes. In this case I've found that the ignorance and insecurity of the consultants on the project on topics like SAP HANA Tailored Datacenter Integration, infrastructure architecture, datacenter operations, virtualization and other infrastructure related disciplines, still makes these people communicate (still today!) that HANA can only be installed as an appliance, ignoring the impacts and risk this represents to many customers. Keeping up with aggressive SLAs is all about building a smooth operation. Smooth operations is all about people and processes, and forcing the introduction of an appliance in this scenario makes the risk and cost of change go sky high. This customer was so relieved from listening me guiding him through what is SAP HANA Tailored Datacenter Integration, and the current support status of HANA on VMware;

2   - with a customer that has just finished a successful PoC and is planning the start of the implementation project of HANA, having the customer more knowledge (through their research and search for real experiences from other customers) than their implementation consultants on what can be done today in terms of HANA virtualization, they saw the start of the project blocked because the consultants in the project said that if he decided to virtualize HANA they would be out of support from SAP! You are afraid of what you don't know. Unfortunately I had to be the one to clarify that the negative impact of virtualization of HANA was only of performance and not at all of functionality. This customer was adopting HANA for functionality purposes, and having processes going from 53 minutes on Oracle to 16 seconds on HANA, the discussion of if "on physical it could be 15 seconds" was just irrelevant compared with the cost avoidance that virtualizing their 700 GB HANA instance represented. How much were worth 1 or 2 seconds in these scenario? Non of the consultants working with this customer had the capacity of putting things into perspective. Ignorance is really a killer of faster HANA adoption;

3   - with a customer that has been in production for about 2 years, that we tried to have him adopting a TDI scenario last year, we got to meet him again because he found out that the cost of operations to sustain their SLAs, and the cost of change derived from their business growth and evolution, was just too much as a consequence of having implemented the appliance with internal storage only. It took almost 2 years for them to agree with me, and that the OPEX of operating that scenario over 5 years would far exceed the CAPEX saving of buying that appliance. More, in their case, 1 year was enough for their increase in OPEX to exceed their saving in CAPEX. Being glad to hear them say "you were right", even if it was almost 2 years later, I have to say it could have been avoided. I don't feel better with my ego, just sorry they had to go through such pain. Again here, ignorance and fear of the unknown was a key road blocker to adopt HANA more extensively in their datacenter. Implementing HANA, and operating HANA against aggressive SLAs are two very different things, and more education on what operations implies might do some good to many of the people talking to customers to adopt HANA. I'm so glad for the time I worked on operations. Priceless learning!

So, let me - once more - based on these real customer experiences explain the rationale of implementing TDI infrastructure for SAP HANA, and why virtualization makes sense for many scenarios.

Stay tuned as I'll bring to my blog the arguments learned from these 3 customer engagements, so that other customers starting now this journey, can learn from them, and also force the hand of the consultants their are working with, fighting back the ignorance that keeps delaying HANA adoption, or making it way more expensive than it could be.

Do not let the ignorance on what is possible today, complicate your journey towards HANA adoption!

Mind Blowing Possibilities with XtremIO for SAP Application LifecycleManagement

Some weeks ago, meeting with the SAP Functional and Development teams of one of our global partners, I had one “Eureka” moment.

It all started with a discussion about what do SAP Functional and Development teams complain more when interacting with infrastructure teams. And the team immediately started to list those things.

They said: “it’s always the same things, on every customer, on every project, being on implementation phases or on maintenance phases”.

And this took me to one unexpected journey of discovery how one technology can really transform the way organizations have always thought of SAP Application Lifecycle Management activities, and remove the “accepted limitations” they were thought to live with.

I’m not much into talking about specific Infrastructure Technologies, but this one blew my mind, and I’m sure many SAP Customers, that will need to keep operating their Netweaver Systems ABAP still for many years to come (because moving to HANA will still take time), will realy appreciate this perspective.

It's all about making simpler all the process involved in getting new code to production, and helping organizations get faster to market. In the SAP world, this process of moving code from development down to production is called Application Lifecycle Management, and through this post I'll be sharing my reflections together with SAP Functional consultants from System Integrators and customer organizations on how EMC XtremIO is unique in transforming this process.

So, where it all started? On one of those meetings where you think that you might got there by mistake…

I was planning to go and meet the SAP Basis team, and I found in the room the guys from SAP functional consulting and SAP application maintenance.

               The Business Challenges

Stepping back a bit, and to provide a bit of context, there is always a tension between what Functional Consulting teams want, and what infrastructure teams deliver. And Functional Consultants keep seeing their plans delayed or complicated because infrastructure teams say: what you want is not possible.

Why infrastructure teams say it’s not possible? Because they either don’t have available infrastructure resources for what they are being asked, or don’t have the budget, or don’t have the time to do it in the requested frequency or time window.

So, Functional teams keep asking, and infrastructure teams keep saying no. No good working relationship will come out of this, right?

What kind of challenges do SAP Functional Consultants face that makes them put so much pressure on infrastructure teams?

• The business users always want information faster, and including the most recent data;
• New business initiatives always come to application teams with aggressive deadlines;
• So, being opening a new store, launching a new product, opening a new online channel, updating pricing rules, or whatever configuration is asked, the business always wants is faster in production than development teams can do it.

This is normal in today’s economy where competitiveness is ever increasing, with global markets, real time connected, and where being the first to market may make or kill a business initiative.

It’s here that concepts like “Agile Development” and “DevOps” are being looked at.

And SAP Functional consultants are the ones dealing with the business owners on a daily basis, having to respond with quality and in time to the ever changing business needs. They are the first face of IT to the business users, and they suffer a lot whenever they have to say no, take more time than acceptable, or miss a deadline.

So, it is important to understand the pain these people suffer with their “internal customers” (the business users), to be able to really do something in IT that is meaningful to the business.

               The IT Challenges

Being today working for an IT Infrastructure company, I wasn’t there just for the fun of chatting about life, so the conversation continues in my intent to find opportunities to help them help their customers.

So, further ahead in the conversation I asked: and does infrastructure impact your ability to meet those requirements in any way? Remember that for SAP Application Teams, infrastructure is the SAP Systems Administration Teams (also known as the Basis Team).

And that’s where the conversation got interesting infrastructure wise!

They mentioned things they would like infrastructure teams (meaning the Basis Teams) to provide them, which they almost never get. And started by saying “it’s always the same 5 or 6 things”:

1. Batch Performance in Production is never good enough from the end user perspective;
2. Be able to have large datasets in non-production systems for better unit testing is always a challenge as there is no space on those systems;
3. Being able to have a freshly updated Test system with a full copy of production data for more comprehensive testing, as many times the cost and time to refresh test systems is so much, that they are only update every 3 or 6 months and they would like to have it every week;
4. Being able to deploy Sandbox systems fast to explore new functionalities, as some times they get questions from the business, and not being sure if that is available on a new version or a new component they haven’t installed yet. So being able to spin up Sandbox systems fast and cheap would be great;
5. Being able to take a “photo” of the test system before a “potentially destructive test”, and then be able to roll back that test system fast and as many times as needed to that picture until the problem is solved, as indeed many times problem solving, due to time pressure is done through trial and error;
6. Being able to do load and report testing on non-production systems with similar runtimes as production systems, as sometimes processes that in production take 1 hour, in non-production take 10 hours, implying longer test cycles.

This is very interesting as it’s not often that you are able to map the business value of a component very low in the infrastructure stack, and these things can really make a difference in a company’s competitiveness.

Here you could say: but this is all just a matter of buying some new or upgrade/expand the existing infrastructure.

               The balancing act of Cost and Benefit

Then, why don’t companies just buy new technology components or expand existing one’s capacity? Why have SAP Application Teams learned to live with these limitations?

Sometimes "we techies” forget that organizations don’t buy technologies just because they are the fastest, better or coolest! Organizations buy IT to serve business purposes, so there need to be a business rationale in every investment decision.

And things are as they are – not as good as the business users would like – because there is an associated cost. Here companies try to find a balance between the total cost of ownership (the purchase cost of a technology plus the cost of operating it), and the expected business impact / benefit of having it or not.

In the end, you invest in production to have a reasonable platform the business can live with, and you minimize as much as possible the investment in non-production systems as the perceived value is minimal. At least until the pain I described starts to hit hard the business.

               The value of XtremIO for SAP Application Lifecycle management

And this brings me to my breakthrough. My “eureka” moment. And I say this, because all of this impact was not completely obvious to me until I had those discussions.

XtremIO can really address the Business Challenges I’ve described above, and overcome the IT limitations they imply in a very cost effective way.

I wouldn’t be able to explain in detail here the architecture of XtremIO and each of its functionalities, and there are better people to do that than me.

So, let me instead focus on what XtremIO functionalities mean to each of the 6 challenges I mentioned above.

I’ll go into the details here, so this will be a bit long, but hopefully will help both SAP Applications Teams, SAP Basis Teams and Infrastructure teams understand what this means for each of them:

1. Batch Performance:
1. Most companies still have the majority of their systems on rotating disks. And no matter how good they are, they are never as fast as the business would like.
2. XtremIO by being an all-flash array, it will automatically speed up the system performance.
3. The numbers we are seeing show 2 to 3 times performance improvement in batch processing (so a 1 hour job going to 30 or 20 minutes), and this without any application migration, performance tuning or other change from the operating system upwards of any kind.
4. Meaning, getting this kick costs little to nothing.
5. Two important notes: the more a batch job depends on physical database reads, the better the improvement. So any type of processing on SAP Systems with very low “DB Time” (DB Time is well known to SAP Basis teams, is measured in transaction ST03 for SAP Systems based on Netweaver ABAP, and represents the part of the total run time of a process that was dependent on database response), will see little improvement.
6. The other note to “little to no cost”. Here I’m thinking about the cost that represents things like OS/DB migrations and ABAP code changes due to upgrades, which is often way bigger than the cost of an infrastructure component. So, not having to do anything at the application level is a huge cost saving. Of course there is always the cost of the system, and the downtime of implementing it, as doing infrastructure projects always implies at least a little downtime.But here the costs are in line with other investments on rotating disks, an the downtime will be minimal.
2. Large Datasets on Development and Quality Assurance systems:
1. SAP Basis consultants have learned to make copies of data in many ways:
1. Remote Client Copy;
2. Export/import;
3. Using SAP Test Data Migration Server (TDMS);
4. And through database specific tools.
2. In many customers refresh of data wasn’t done at all, or not often enough because of one of the following:
1. There was simply no space on the non-production system to hold the production database;
2. On development systems, overwriting the database might make the customer to lose the version history of developments which is a problem in terms of compliance for many organizations;
3. Due to one of the 2 above points, they used copy methods that had very long run times, or had an impact on production, and so needed to be planned carefully as might imply either unavailability of production, or severe limitation on production usage during the copy.
3. XtremIO Deduplication feature makes that a copy of a disk volume, occupies no space on the storage. So, if you write the same block at the storage level 3 times, you only occupy the space of 1, not 3.
1. This means that the space limitation ceases to exist. You can copy things as large as you want, as many times as you want, and you will only occupy the space of the source.
2. On development systems, there are procedures from SAP to export those things (version history of ABAP objects, etc) and I’m planning to do a bit more research on that, and maybe write a blog post on it. Nevertheless, for environments where this is not a constrain (or new implementations), now customers can also build a new development system from a copy of production.
3. The only caveat here is if the customer has strict confidentiality requirements, and uses SAP TDMS or equivalent solutions to scramble the data. In this case XtremIO will only help by speeding up the reads on the source system and the writes on the target – so speeding up the overall copy procedure, but would not provide the deduplication benefit. The systems would still occupy the full space.
3. Regularly updated test systems with full copies of production:
1. The pain here comes from 3 things:
1. Most of the times production is one 1 Tier1 storage array, and non-production systems are on another Tier2 storage array. So, copying multi-terabyte databases from one array to the other is heavy lifting.
2. Many times, the Tier2 storage system doesn’t have enough capacity to hold the production database. It’s very rare to find a customer with databases larger than 10 TeraBytes that have the same space on their Development, Quality Assurance and Pre-production systems.
3. Copying an SAP Database from production to a non-production environment is not only about copying the storage volumes, as there are a number of tasks that need to be done at the database and ABAP level to repurpose the system and have it ready for testing.
2. And XtremIO addresses these 3 things:
1. XtremIO’s architecture when you make a copy of a disk volume, due to its deduplication feature, it only creates pointers, does not copy the data. So, being on the same array, you don’t have neither movement of data neither read/write of data to copy it. It’s just like taking a photo of the data: takes seconds! I’ve tested in the lab and seen it at work. Amazing! Also, if you study the architecture of XtremIO this will become obvious to you.
2. The system deduplication mechanism also makes that, when you create a copy of an existing database at the storage level, as it is an exact copy, will be fully deduplicated, so not consuming any space at the storage level. Yes, this is true, and no, it doesn’t imply an impact on performance of the production database. Of course as you start to change the data on the copy, the changes will start to occupy space on the storage, but my experience as a customer shown that the volume of changes in a non-production system is always very low. So, maybe, just with a max of 10% of the total size of the database, you can have a full copy of production! Lab testing showed that creating 3 additional copies from 2 source databases (one with 340 GB and the other with 126 GB), ocupied only additional 7GB after all the ABAP post processing was completed (BDLS included - SAP Basis teams know what I'm talking about). So instead of going from 466 GB to 1272 GB, we went to 473 GB. How cool is that?
3. And last but not least, is now under development the integration of XtremIO with SAP Landscape Virtualization Management software. For those who don’t know about it, is an SAP software that orchestrates all the steps involved in an “homogeneous system copy” process, including the ABAP post processing. So, it will enable to realy have a copy if the system with the click of a button. And in minutes (or few hours depending on how many tasks have to be performed in the ABAP post processing).
4. Easiness to deploy sandbox and training systems:
1. In many customers, applications teams cannot just get a system to play around. And one reason is because building a new system consumes resources.
2. Now imagine that:
1. With XtremIO deduplication, new copies of existing systems consume little to no space on the storage;
2. If you are running virtualized, you can deploy this system overcommitting RAM and CPU (so with little or no resource contumption) as it is intended or a single user or few users just to learn or “play around”.
3. And if you add automation with LVM, even the effort of building the system goes away.
3. So, wouldn’t this change the way development and application teams have worked until today? 
1. True that in many cases doing a client copy, and building a new client was a way to solve some of these things, but didn’t provide the opportunity really to go around and change also repository objects. 
2. This way, there would be no restrictions, since SAP LVM also has a “system destroy” option to then delete the system once it is no longer needed. And this would take me into “cloud discussions” and things like self-service portals… but will focus at this stage only on the enabling technologies, from an affordability point of view.
5. Being able to rollback a system fast and as many times as needed:
1. This has implications way further than just test systems, as it can be applied to backups of production systems, build of parallel landscapes for projects like SAP system version upgrades, and also backup of non-production systems.
2. Again, the magic here comes from XtremIO deduplication and snapshot functionality, which works in a unique way in the market.
3. Since doing these operations consumes little to no capacity, and have no performance impact, it opens endless possibilities, as you can create as many copies as you want (of course within the limits of the XtremIO specifications) for whatever purposes you want. So, you would have production grade backup through storage snapshots for all production and non-production systems at “no-cost”. And no cost I mean that these copies do not occupy space or impact performance, which is a major constrain on traditional systems.
4. Also the fact that the system has a very intuitive and simple graphical user interface, makes it easier, faster and less risky to perform these operations. No risk of the storage admin run the wrong command and impact production.
6. Being able to do testing in non-production with production alike performance:
1. Repeating myself here, the magic comes from the snapshot technology that XtremIO uses, it’s deduplication feature implementation, and the fact that it is all flash.
2. This allows the copies of the productive disks to perform as well as the originals. So, testing will be much faster as well.

Conclusion: having infrastructure teams say YES, and drive innovation

So, I truly think XtremIO is a “game changing” technology, and is disruptive in the way it allows to challenge long time limitations and constraints on SAP Application Lifecycle Management tasks.

It took me these interactions with SAP applications stakeholders to get this “Eureka”. 

I’ve been digging on XtremIO for professional reasons since June last year, but I was struggling to see the uniqueness, and especially for the SAP world. Ok, it is fast and has lots of cool features, but looking at it from the SAP Applications Perspective, so what? What is different or unique compared with other technologies in the market?

In the end this is all about having Infrastructure teams being able to say YES to more of the requests they get from the functional teams, enabling the functional teams to serve better the business users, and so driving better time to market, and in the end, better business agility.

And having already shared this with other persons in customer and partner organizations, validated my reasoning. XtremIO is really unique in the market from this perspective.

One Applications Director at an organization I spoke with told me that this would enable him to shorten dramatically SLA’s with the business in regards to response time of requests for change, while reducing the costs of “unit testing” and “end user training” dramatically.So, he would fund an infrastructure project to get the SAP Systems on it, as the benefits were tremendous for them.

There is a lot more I could say on XtremIO, but my goal here was not to make a technology review, but rather – leveraging my knowledge on XtremIO architecture, together with my knowledge and experience on SAP Systems Operations and Applications Lifecycle Management – to show how a technology can indeed transform for the better an organization in terms of iits business agility.

A final though: another customer saw this as an outstanding opportunity to take out cost of his current operations costs (both at application maintenance level and on infrastructure operations), to release budget to invest on new initiatives, like funding the adoption of SAP HANA.

Closing by saying: it will still take some years for customers to migrate all their systems to HANA, and being able to improve them at these many levels, with no application changes is of tremendous value for many organizations.

If you want to know more about EMC Engineering testing with XtremIO, just read the latest whitepaper I've worked with EMC X-BU Engineering on the topic, that you can find at: http://www.emc.com/collateral/white-papers/h13859-xtremio-sap-wp.pdf
 

Glad to be back to blogging after some crazy months overloaded! Hope to come back soon, again on my favorite topic: HANA!

First feelings out of SAP TechEd && dCode Berlin

This is the early morning of the first day of the conference, and just got out of the key note session.

If anyone had any doubts, it became crystal clear: the future of SAP Innovation will be driven by SAP HANA.

With SPS07 HANA has really became a mature platform in terms of datacenter integration options, and all the innovation driven by the possibilities it brings to business, make a overwhelmingly compelling case for companies to start adopting HANA within their datacenter portfolio.

So, I truly believe the question today is not on "whether companies will adopt HANA" but more a matter of "how and when" will companies bring HANA into their datacenter portfolios.

A couple of things caught my attention, and let me share those with you.

First the affirmation that HANA and Fiori will represent the full reinvention of SAP applications. The level of possibilities offered by HANA together with the user experience improvement offered by Fiori will completely reshape SAP applications as we know them today, so every day customers wait to start this journey, will represent more time without seizing the benefits this simplification could be bringing to their organizations.

The next one is that SAP is very serious about cloud. What I got is that SAP is playing on the full front: IaaS, PaaS, SaaS as well as making all these 3 models work on a fully public model, on a fully private model as well as on a hybrid cloud model. I understood that on the IaaS and PaaS spaces SAP is opening for the partner community to contribute, and considering the dramatic reductions of data footprints being observed (one example showed a 10TB BW coming to a 800GB database on HANA), running some of these applications fully virtualized (using virtualization technologies like VMware), will bring the benefit of flexibility, enabling customers to operate not only on a Hybrid Cloud Model, but most of all, giving customers the flexibility of changing providers and moving between multiple PaaS and IaaS providers. Working on a hybrid model with some components subscribed as IaaS, others as PaaS and others as well as SaaS will definitely be a possible model going forward, enabling each customer to chose the right option for him, based on his strategic, financial, security/compliance and technical constraints. These are exciting times full of possibilities!

And the third topic I would like to highlight is how HANA platform and the Fiori user experience are enabling the transformation both of business models, as well user productivity. The example of s-Fin and the "Big Washroom Data" really provoke users and business decision makers to start thinking on a "what if" perspective, and start disrupting their own business to enable them to leap forward on this new hyper connected world. Getting the information to the fingertips of business users, enable them to manipulate and analyze it on the fly, along side with the possibility to integrate in real time "machine data" and act upon it in real time, open possibilities up until now unavailable to SAP customers.

These are exciting times for all of us technologists working on the SAP world, and more than ever, skill sets that span technologies, and bridge business as IT, also connecting multiple technology disciplines to get them all working together will for sure see increased demand, as on this new world, a silo view won't do it anymore.

Stay tuned for more news and perspectives coming from my learning at this SAP TechEd && d-Code 2014 in Berlin.

ScaleIO - A New way to configure storage for SAP HANA?

Just a couple of days ago, EMC's ScaleIO got to be supported by SAP to be used in productive environments both for SAP HANA and traditional SAP Landscapes.
SAP's support statement can be found on the following SAP Note: https://service.sap.com/sap/support/notes/800326

For many, this will have little meaning, but for some this will be a major breakthrough.

Let me state from the start that it's my true belief that for large enterprise customers, having a SAN based storage config is the best way to deploy SAP Systems, an in particular SAP HANA. My posts on this blog explain why i believe that, and it's a factor of performance, TCO, flexibility and operations aspects.

But the fact is that mainly in the service provider business, some organizations are looking to "white label" servers with direct attach storage, forming large pools of resources, as a cheaper infrastructure option in this very competitive "public cloud" world.

And in that case, you will want a couple of things:

• Performance, of course;
• But also redundancy;
• Scalability;
• and ease of management.

In the SAP world, so far, the only way to get the redundancy and scalability was using IBM's GPFS, which is a clustered file system providing many redundancy and scalability characteristics.

There are lots of merits and value in GPFS, but I think GPFS is the wrong tool for environments like databases (for example see my blog post on block vs file here). Also the feedback I'm getting from customers I meet using GPFS, say it's a nightmare to manage, implies unacceptable downtimes to scale, and implies as well operations costs that are not the most affordable in the market.

Well, ScaleIO is a technology that allows to aggregate the direct attach storage of many servers into a single "virtual SAN alike" block storage pool.

And as I've written on an earlier blog post, for database workloads, I believe that "block" access to disk is the right option. After all the databases read and write blocks, and the same happens with SAP HANA.

So, what ScaleIO allows is to:

• get redundancy into direct attach storage my ensuring a copy of each server's data on another server;
• get awesome performance by distributing the data of a filesystem attributed to a server accross all servers in the pool (all application servers are at the same time storage servers for their peers), which makes this solution to perform better the more nodes you have in the cluster (of course LAN network planning plays an important role here);
• scalability is natural in the design of ScaleIO, and the best is that you can add servers to the pool and re-balance volumes automatically behind the scenes. the same automatic re-balancing happens as well when you remove a server;
• and the best of it, is that many of these operations are done online.

More information will come out explaining what is ScaleIO, how it works, and how to configure it for SAP HANA environments. EMC is working on a whitepaper documenting how to configure ScaleIO for SAP HANA environments which should not take long to be published.

Meanwhile, check out SAP Note 800326 for the official support statement from SAP for ScaleIO, and if you want to learn more about this technology, it's benefits and how it might fit on your datacenter strategy, drop me a message and I'll be happy to help.

One final note: if you are a fan of server based storage, you need to scale-out, you would like alternatives to GPFS, and would like to have more choice for this kind of setup either with IBM servers, or other server manufacturers, the best news of all, is that NOW you have!

Stay tuned as more new will come on this soon.

SAP HANA Network Requirements Whitepaper has been published

Just wanted to bring your attention to the publishing of the “SAP HANA Network Requirements” whitepaper, that can be found at: http://www.saphana.com/docs/DOC-4805

I’ve talked with some of you in the past in regards to:

• What is the needed throughput for certain LAN segments;
• What is the maximum latency admitted for synchronous replication;
• What network segmentation must be implemented for HANA Network Integration;
• Etc.

All of these and other questions are answered in this whitepaper.

For me, some aspects within the document caught my attention:

• Recommended to have a maximum of 1 ms round-trip in the network connecting two sites when intending to implement synchronous replication;
• Demand for the HANA Internal Network (for inter-node communication in a scale-out cluster) to deliver minimum of 2x9 GBit/s in full duplex;
• Recommendation to have up to 9 network segments (with the implied demand for server network ports) for performance and security reasons…

Well, if this is a topic of your interest, be sure to reserve some quiet time to have a close look at this document as it is indeed very detailed.

I believe there are some aspects I would argue against or add something, but overall is a very good document for all that want to get started on these topics.

Also remember that I keep an exhaustive list of relevant SAP Technical Document to make it easier to you all to find what you are looking for.

You can find that on my blog at: http://sapinfrastructureintegration.blogspot.com/p/reading-list-for-sap-hana.html

Have a great reading!

Does SAP HANA Require NAS storage? No it does NOT!

Although I've written quite a bit about this, there are still many confused about whether SAP HANA needs a NAS storage.

So, to make it clear, NO IT DOES NOT!

What SAP HANA requires is a shared file system in the same way the old SAP Netweaver system had a shared file system that was SAPMNT.

The same happens with HANA and his is called /hana/shared and must be accessible by all HANA nodes, in the same way it happened with SAPMNT in the Netweaver world

So, using a NAS storage / gateway is a way to achieve this goal, but is not the only one.

For example, in the same way it was done for the Netweaver's SAPMNT, you can use a Linux server with PaceMaker to export an NFS share out of a block device in an high available way.

The consideration you need to take here is the size of your cluster. So, if you are going for scale-out clusters with a large number of nodes, you don't want this NFS share to become a bottleneck and a problem, so ensuring proper network connectivity (latency, throughput and availability) requires more careful planning than just throwing it to any existing Linux machine.

I've written a lot on why you should use block devices for HANA.

As a short reference you can read about:

• the SAP HANA Storage Connector for Fibre Channel at: http://sapinfrastructureintegration.blogspot.com/2014/07/sap-hana-fiber-channel-storage.html
• my long discussion on why some HANA "architecture" myths are outdated, being one of the topics exactly why Block is a better option for HANA persistency over NFS.

All this said, using a unified storage that provides both block and file connectivity may also serve your needs, by using the block connectivity for all the data and log devices, and the NAS functionality for the HANA SHARED.

Again, this is a possibility, not a need.

Finally, considering that most HANA projects I'm seeing these days are for Suite on HANA, which implies single server implementations, doing this in a TDI setup, by connecting two servers to external storage for high availability, and while installing Linux add as well the clustering software package just with the goal of protecting and exporting the "HANA shared" NFS share might be the simplest more integrated option. (you can read more about running SAP Business Suite on HANA in a TDI setup on my blog post here: http://sapinfrastructureintegration.blogspot.com/2014/09/running-sap-business-suite-on-hana-in.html).

Again, these are all possibilities, and fortunately, as HANA has matured a lot over the last year, now you have these well known options also available for HANA, further providing you choice in a way that you can standardize your datacenter practices.

As a conclusion, HANA is a lot more open today than it was just 1 year ago, so don't go for proprietary solutions that having been the first, are not the easiest neither the best for most customer cases. Take your time to evaluate current architectural options and make a decision to have the most standard possible application architecture and building blocks, across your datacenter, including HANA of course!

Having this uniform architecture across the datacenter will drive down your risk, enable more agile changes, and in the end a more streamline and cost effective operation.

Hope this helps, and feel free to shoot me any deeper technical questions you may have in this regards.

Running SAP Business Suite on HANA in a TDI Infrastructure? Yes you can.

Lots of discussion has been going around in regards to the following questions:

1.       Can Business Suite on HANA (SoH) run in an infrastructure implemented as Tailored Datacenter Integration (TDI)?

2.       What are the storage sizing guidelines for Business Suite on HANA in a TDI configuration?

 

Today’s reality for SoH on TDI infrastructure

Let me be very direct and give a very short answer to these questions, and then explain why these questions are coming up, and what the source of confusion is.

1.       YES !!! Business Suite on HANA can run on a Tailored Datacenter Integration infrastructure. You can confirm this by reading "Question 5" of the "General Information" Chapter in the SAP HANA TDI FAQ available at: http://www.saphana.com/docs/DOC-3634  (note that this document is regularly updated, so make sure to check for the latest version online. My comments are based on the August 8th 2014 version). There is written: "SAP HANA Tailored Data Center Integration can be used for both scale-up (single-node) and scale-out scenarios. For scale-out scenarios, SAP HANA TDI is limited to 16 nodes."

2.       The storage KPIs that need to be fulfilled by TDI configurations, both in the case of BW and Suite on HANA are the same, as defined by SAP on note 1943937. So, the EMC storage best practices for SAP HANA TDI apply in the same way both for Suite on HANA and BW. Nevertheless, as Suite on HANA may involve higher space requirements, there is always the need to confirm whether the "minimum requirements" provided on the EMC Best Practices Whitepaper provide enough usable space for the node size being connected to the TDI storage. In case of need for additional space, disk count should be incremented.

 

Reasons for customers and consultants being confused

So, why are these questions coming up?

The explanation for these questions comes from the SAP FAQ available at http://www.saphana.com/docs/DOC-3634 and in particular what is written in "Question 11" of the "SAP HANA TAILORED DATA CENTER INTEGRATION WITH ENTERPRISE STORAGE " chapter.

There is written:

Q: Why are there different KPIs for SAP HANA appliances and for SAP HANA TDI with Enterprise Storage?

A: SAP considers appliances as the hardware offering providing highest quality and highest performance for SAP HANA systems. In SAP HANA appliances, the hardware components are solely used for the SAP HANA systems running on it; there is no sharing of hardware with other systems. Therefore, SAP’s requirements for SAP HANA appliances are higher than for SAP HANA TDI infrastructures...

 

This has led for many people to raise questions on whether Suite on HANA could be ran on a TDI setup, and also for lots of people to ask what are "our special recommendations to configure storage for Suite on HANA KPIs".

As you can clearly understand, there are in fact more demanding KPIs for Suite on HANA dedicated appliances, and some customers start to think: “I'm buying HANA to speed up my processes, and then going on TDI makes it slower”.

I have to say that some consultants have also contributed to build confusion on this topic.

 

                Running SoH in TDI does not mean running slower!!!

This reasoning is not completely true, because the fact that SAP's requirements for TDI are lower than for appliances does not mean that special TDI "shared" configurations of enterprise storage systems cannot meet them.

In fact EMC, together with Cisco, has just certified a 3TB Suite on HANA special configuration using external storage. This certification submitted the system to the most demanding “SAP Business Suite on HANA” storage KPIs, and can be found at: http://scn.sap.com/docs/DOC-52522#jive_content_id_SAP_HANA_SoH_optimized_hardware_SLES_configurations

This proves that external storage can fulfill the most demanding SAP HANA Appliance KPIs, and that EMC has both the technology and knowledge to do it.

 

                Again, it’s all about the TCO.

But, from reading the full SAP HANA TDI Q&A SAP has published at http://www.saphana.com/docs/DOC-3634 in "Question 6" of the "SAP HANA TAILORED DATA CENTER INTEGRATION WITH ENTERPRISE STORAGE " chapter you can realize that depending on your specific application workload profile, it may happen that not meeting a single KPI may not have any impact on the observed performance of the system.

So, if you want to run SAP Business Suite on HANA on a shared infrastructure ensuring that the system meets the most demanding KPIs, stay tuned as EMC’s recommendations will be coming soon in the future!

EMC engineering is continuously working on improving their recommendations for SAP HANA storage integration, and I’m sure more openness and simplification will come in the future alongside with more options for customers, even those requiring the most demanding performance numbers in a shared infrastructure.

Be aware though, that it may happen that current TDI recommendations are already delivering most of these more demanding KPIs, and that this solution should be enough for the majority of the situations.

It’s important to realize this, because often we forget that improving a few micro-seconds in latency, or a few MB in throughput may imply a larger HW investment, as resources that otherwise would be shared, to guarantee such demanding requirements will need to be dedicated.

So, think well on how these small improvements are important to you before making the decision to go for “the best of the best of the best”, because that has a cost (being on CAPEX or on OPEX, as if you save in one, will most likely be more hit on the other). Meaning, maybe for your specific business case having just 100 times improvement instead of 110 times improvement is good enough, and at a much lower cost! Just think about it.

 

                The facts as of September 2014 (yes, all things HANA are evolving very fast!)

In summary:

·         YES, suite on HANA can run with TDI infrastructures

·         Today, SAP HANA Storage KPIs for TDI do not take into consideration what is the application (BW or Suite) neither the node size. So, our recommendations ensure that those KPIs are always met.

·         The fact that SAP's required KPIs for TDI are less demanding than the appliance KPIs for Suite on HANA, doesn't mean that EMC's configurations for enterprise storage cannot fulfill many of them.

o   In fact, in some real world examples I saw, when measuring the KPIs in a VBlock 700 configured under the “current standard TDI guidelines”, we achieved more than 90% of the most demanding Suite on HANA KPIs, and on the ones failed we were very close. Meaning, very close to maximum performance KPIs asked for SAP HANA SoH optimized appliances!

·         If you want maximum performance on a shared storage infrastructure, for example to take advantage of HANA HA, or disk based system copy, backup or DR, for a started EMC just got the first evidence of our capabilities published. Find the Cisco 3TB SoH optimized appliance with VNX5400 external storage at: http://scn.sap.com/docs/DOC-52522#jive_content_id_SAP_HANA_SoH_optimized_hardware_SLES_configurations

o   But remember, the things in the certification matrix are just a starting evidence of what can be done. Do not hesitate to ask more questions and find YOUR desired SoH config.

o   Out of the learnings from this certification, EMC is still working on providing concrete guidelines on how to configure external shared storage in a way that the appliance KPIs are met. So, despite the facts today about SAP HANA TDI KPIs being the same for SoH and BW, as this is a question coming around quite often, for those customers that want the best performance in a shared infrastructure, EMC will be providing some further info in the future. Stay tuned.

·         If you want to get a better understanding of the impact of the various HANA storage KPIs and the potential performance impact of not meeting some of them, I advise the reading of:

o   "Question 6" of the "SAP HANA TAILORED DATA CENTER INTEGRATION WITH ENTERPRISE STORAGE " chapter in the SAP HANA TDI FAQ, that you can find here: http://www.saphana.com/docs/DOC-3634  

o   Read the SAP HANA Storage requirements whitepaper, where SAP explains the IO profile of HANA, and what each IO KPI means so that you can evaluate its potencial impact on the performance of a specific SAP HANA System. This whitepaper also covers storage sizing. You can find it here: http://www.saphana.com/docs/DOC-4071  

If at the end of this discussion you still have questions on whether running Business Suite on HANA with a Shared Storage TDI infrastructure is a good idea, make sure to read in detail the "IT Management Fact Book for Business Suite on HANA", that you can find here: http://www.saphana.com/docs/DOC-4223  

For me, this document makes it clear that TDI is the future for HANA Datacenter Integration, simplifying HANA operation's practices.

 

Final thoughts

If you watched Bill McDermott’s (SAP’s CEO) keynote at this year’s SAPPHIRE, for sure you remember the title: Simplify Everything, Do Anything.

Well, it’s more than appropriate.

SAP is full steam on simplifying SAP HANA adoption for its customers. I’m interpreting that in the way it will mean also opening further the datacenter integration options of SAP HANA, and providing more choice to customers.

So, I stick to the conclusions I wrote on my blog on TDI from January this year, where I made an analysis of SAP HANA evolution.

My advice here when making a choice would be: if any provider or consultant comes to you saying that SAP HANA is very complex and very restricted in options, take a second guess. As either he is trying to corner you to his proprietary solutions or has no real clue on how much HANA has evolved in this last year.

SAP HANA is in fact becoming a normal application in the datacenter, with its unique workload pattern, of course. But its datacenter integration practices are everyday further aligning to what is normal for IT operations in most datacenters around the world.

And these are good news!

·         Good news for customers in the first place, as it will be simpler, faster and cheaper to implement SAP HANA (big example here is the support for HANA on VMware).

·         And good news as well for SAP, and this will enable an increased pace of HANA adoption.