SAP Landscape sizing and volume consolidation with ANF
SAP Landscape sizing and volume consolidation with ANF This Blog does not have the claim to be all-embracing and should not be seen as single source of truth. I only would like to open a much broader sizing discussion and present a different view on this topic. The second part will try to explain how volume consolidation works. Sizing an SAP Landscape is usually a very difficult task because there are so many different, sometimes unknown, parameters and values to be taken into consideration. Most of the sizing tools only look towards a single system. This is surely okay for the VM (CPU) sizing however, when it comes to an optimized storage design most tools are not seeing the to avoid complete SAP Landscape and this obviously are not optimized for the best TCO for the customer. Even when a storage design looks more expensive in the first view, it can be the basis of a much better TCO when all IT costs are taken into consideration. Especially storage changes and optimalizations are usually very complex tasks which sometimes even require longer system downtimes. To avoid unnecessary outages the SAP landscape, need to have a very flexible storage environment which allows the customer to grow and react on changes or different requirements from the application very quickly. All this together guarantees optimized TCO and a smooth and reliable SAP landscape for our customers. Most of the effort and cost is going in the landscape management and administration. Only 25% of the overall costs are going into the Infrastructure investment. Source: https://flylib.com/books/en/4.91.1.14/1/ No support of NVA in the Data Path!!! Because of performance and latency reasons it is not supported to configure an Network Virtual Appliance in the data path of the SAP App server to the DB nor from the DB server to the ANF. This is also stated in SAP note: https://launchpad.support.sap.com/#/notes/2731110 Performance tuning To optimize an SAP Landscape, it is essential to monitor the used capacity (CPU, Network and Storage) continuously and evaluate the business needs with this outcome to be able to align and optimize quickly to meet the business requirements. The IT must catch up with the business not the other way around. It is a continuous process … Monitor ->Evaluate ->Adjust -> Monitor….. Storage landscape sizing based on Azure NetApp Files (ANF) Before this new feature was introduced there was a fixed performance ratio for the volume, depending on the Capacity pool QoS we got 16, 64 or 128 MB/s per Terabyte volume size. After implementing the new “Manual QoS Capacity Pool” (public pre-view) feature for ANF the storage sizing is much more optimized than with the previous fixed ratio between performance and volume size. This new feature allows to optimize the volume throughput per volume. Now, also small volumes can benefit from a higher throughput which helps to optimize the overall design. The challenge now is to find a good mix of “slow” and “fast” volumes in the Manual QoS Capacity Pool. This challenge gets much easier by larger Capacity Pools. I will give some sizing examples where I can demonstrate how easy it is when we focus on a landscape - and not focus on a single system design. ANF Storage QoS classes In ANF we have three different storage classes available. Note that this performance OoS pool setting is only there to manage the capacity of the storage system. The data will always be written to the same ANF backend. We differentiate between: Capacity QoS Performance per terabyte volume size Standard 16MB/s Premium 64MB/s Ultra 128MB/s Of course, different costs are associated to the different QoS classes. The cost calculator is available under: https://azure.microsoft.com/en-us/pricing/details/netapp/ Storage sizing … different approach To find the optimal Capacity Pool size we need to calculate the individual storage requirements. And then integrate this individual number into the Capacity Pool calculation. This will present then the “Big Picture”. The big benefit of ANF here is that nothing is written in stone, size and performance can be adopted dynamically during normal operation. Changing size or performance quota does not need any downtime for the customer. System RAM vers. HANA DB size….It is essential to understand that the system RAM cannot be taken as the DB size of HANA. There is space in RAM required for OS operations, HANA delta tables, HANA temporary tables and so on. So the actual DB in size in memory if about 50% of the RAM. This is also the “golden sizing rule” for SAP HANA. Source: SAP TDIv5 Memory guide To calculate the required storage for the system this sizing table should help to calculate the overall storage requirements. Important is not the single data-, log, shared or backup volume, only the total value is important here. For larger VM’s (4TB) those Values are very rough estimations. The backup concept has massive impact on the size of the backup volume. Shared Volume: Shared between group of systems, like DEV, QAS and PRD. Shared Volume also contains /usr/sap. Backup Volume: Shared between all instances. (1x DB Data+ 2x Log Volume + X) SnapShot reserve is already calculated in the data-volume – RAM size not equal DB size VM Main Memory Data Vol (GB) Log Vol (GB) Shared (GB) Backup (GB) Total (GB) 256GB 300 300 300 900 1800 512GB 500 300 500 1100 2400 1024GB 1000 500 1000 2000 4500 2048GB 2000 500 2000 3000 7500 4096GB 4000 500 4000 5000 13500 6192GB 6000 500 6000 7000 19500 Table 1 – overall storage requirement Volume Performance and sizing As a basis for a start design, we estimate a performance quota for DEV, Sandbox, QAS and PRD systems (we stick to the SAP HANA storage KPI’s only for PRD systems). If customers also using their QAS systems for performance testing with the same dataset, it would make sense to design also the QAS storage performance accordingly. Surly this can/must be adopted dynamically if required differently from the customer. SAP is providing KPI’s only for data- and log-volumes. Those KPI’s are equal over all sizes of the databases, this of course cannot be adopted as general guidance for productive environments. Here we know that the throughput is varying heavily from the KPI’s for larger systems. The DB startup time is depending on the data-volume read e.g.: 1 TB DB with 400 MB/s read startup time +/- 20 Min 2 TB DB with 400 MB/s read startup time +/- 40 Min 6 TB DB with 400 MB/s read startup time +/- 1 h 20 Min ---at least here we see a discrepancy of min. KPI These MINIMAL requirements are meant for PRD systems. In general, it is 250 MB/s write for the log-volume and 400 MB/s for the data-volume. It is important to understand that we need to provide more throughput for larger systems. As mentioned, … this is a starting point. System Type 256GB + 512GB RAM % of KPI Data-Volume Log-Volume Sandbox 25% 100MB/s 50MB/s DEV 25% 100MB/s 50MB/s QAS 50% 200MB/s 125MB/s PRD 100% 400MB/s 250MB/s Table 2 – throughput per volume System Type 1024GB RAM % of KPI Data-Volume Log-Volume Sandbox 25% 100MB/s 50MB/s DEV 25% 150MB/s 75MB/s QAS 50% 250MB/s 125MB/s PRD 100% 500MB/s 250MB/s Table 3 – throughput per volume Startup time DB size 0.5TB = +/- 15Min System Type 2048GB RAM % of KPI Data-Volume Log-Volume Sandbox 25% 150MB/s 100MB/s DEV 25% 150MB/s 100MB/s QAS 50% 300MB/s 150MB/s PRD 100% 600MB/s 300MB/s Table 4 – throughput per volume Startup time DB size 1.2TB = +/- 30 Min System Type 4TB + 6TB RAM % of KPI Data-Volume Log-Volume Sandbox 25% 200MB/s 100MB/s DEV 25% 200MB/s 100MB/s QAS 50% 400MB/s 200MB/s PRD 100% 800MB/s 400MB/s Table 5 – throughput per volume Startup time DB size 3TB = +/- 60Min Sizing a Landscape with 10 Systems So how can a ANF storage design for 10 HANA databases looks like? Let’s assume we have 4x 256GB (M32ls) DEV, 4x 1TB (M64s) QAS and 2x 1 TB (M64s) PRD systems System type Storage Requirements (table 1) Performance Requirements (from table 2-5) DEV 4x 1800GB = 7TB Data=4x 100MB/s ; Log=4x 50MB/s QAS 4x 4500GB = 18TB Data=4x 250MB/s ; Log=4x 150MB/s PRD 2x 4500GB = 9TB Data=2x 500MB/s ; Log=2x 300MB/s Backup DEV=100MB/s, QAS=200MB/s,PRD=500MB/s Shared DEV=50MB/s, QAS=50MB/s, PRD=100MB/s Total Storage= 34TB (from Table 1) Total MB/s=(data and log) 3.800MB/s + (Backup) 800MB/s estimate + (Shared) 250MB/s estimated= 4800MB/s Translated to an ANF Capacity Pool Premium 35x 64MB/s = 2240MB/s (we make Backup a bit smaller that it fits into the calculation. Can grow on demand - but it will take some time) Ultra 20x 128MB/s = 2560MB/s Total 4800MB/s Cost estimation https://azure.microsoft.com/us-en/pricing/calculator/?service=netapp Mix of Premium and Ultra 35TB x 64MB/s = 2240MB/s + 20TB x 128MB/s =2560 à 4800MB/s Only Ultra (34TB) 38TB x 128MB/s = 4864MB/s Conclusion: In this case it is much more efficient to choose Ultra over Premium. Only very little overprovisioning and very easy deployment because everything is in one pool. The volumes surely will be distributed over several controller. . Consolidation of ANF Volumes Consolidating HANA Log-Volumes One additional option is to share log-Volumes. Log volumes are not a point of interest for the backup scenarios since there are open files (log files from the database) which cannot be backed up properly. Not all databases are creating the same amount of log information nor requiring the same throughput on the log-volume. Thus it can be very beneficial to share the log-volume among some database systems to benefit from much higher performance for the group of databases which are writing into this shared log-volume. 1 Prod System => 250 MB/s 2 Prod Systems=> +125 MB/s (+50%) = 375 MB/s 3 Prod Systems => +125 MB/s = 500 MB/s 4 Prod Systems => +125 MB/s = 625 MB/s 5 Prod Systems => +125 MB/s = 750 MB/s How to create a consolidated structure with ANF The main reason of doing consolidation is to achieve more with less. Less administration, less resources but more performance and easier administration. Since the performance of ANF is related to the size of the volume it is essential to create a large volume to benefit from this performance quota. Create a meaningful directory structure in this volume to have a good overview of the installed SAP systems. From the application node view this structure is basically invisible. Understanding how ANF is structured and how it needs to be configured Before you can create volumes in ANF for your SAP environment you need to create a NetApp account then a capacity pool and last the volume in the capacity pool. More Info:https://docs.microsoft.com/en-gb/azure/azure-netapp-files/azure-netapp-files-understand-storage-hierarchy#capacity_pools Design concept of multiple SAP systems in one ANF Volume The basic idea behind this is to gain performance and lower the administration overhead of single volumes or default Azure storage. Customers tend to separate non-prod and prod environments, this surely can be done here as well. But instead of managing, sometimes tens of volumes, you only need to manage two or maybe three volumes. This example shows only two SAP systems but surly this can be applied to a very large scale. Create a single volume, here for example non-prod and create for every SAP simple directories in the main volume. For the SAP those ´nested´ mount points are completely invisible. Deployment of ANF with multiple instances Data volumes: If you plan to use SnapShot based backups and cloning, shared data volumes are not a good idea. If you use shared volumes a SnapRevert is not supported anymore because you would also overwrite the data of the other, shared, SAP instances. For all other volumes volume consolidation is always a good idea. If it is required to restore a single file form one instance there is always the chance to go into the (hidden) snapshot directory and copy a single file out of this snapshot into its original location. A shared landscape can look like this: Here you see two DEV, two QAS and two PRD systems in an optimized volume deployment. Another interesting idea is to consolidate volumes by SID. In this case you benefit from the fact that a snapshot would take all three areas (data, log and shared) together. And also, the performance is shared among the three areas. There is some more work to do here before you can clone/refresh the HANA database in this approach.
