the datacore server

The authority on real-time data

The DataCore Server

System Memory Considerations

April 2021 This guide helps understand how a DataCore Servers physical memory is used by SANsymphony and other DataCore drivers and servers. It also gives general recommendations and requirements for optimum performance and stability.

Table of contents

Changes to this document 3

SANsymphony’s cache 4

How much physical memory do I need? 4

When does SANsymphony reserve memory for its cache? 4 How to monitor SANsymphony’s cache's allocation 5

DataCore drivers and services 7

DataCore system drivers 7

The DataCore Executive service 8

SANsymphony features 9

Asynchronous Replication 9

Continuous Data Protection (CDP) 9

Disk Pools 9 Storage Allocation Unit management 9 Encryption 10 Auto-reclamation 10 Manual-reclamation 10

Inline Deduplication and Compression (ILDC) 10

Performance Recording 10 Live and Recorded Performance 10 Historical Performance Recording 10

Snapshot 11

Virtual Disks 12 Single Virtual Disks 12 Dual and Mirrored Virtual Disks 12 Dynamic Data Resilient (DDR) Virtual Disks 12

Third-party applications and services 13

Previous Changes 14

Page | 3 The DataCore Server – System Memory Considerations

Changes to this document The most recent version of this document is available from here: https://datacore.custhelp.com/app/answers/detail/a_id/838

Changes since June 2019 Added Disk Pools Encryption Manual reclamation Inline Deduplication and Compression (ILDC) Updated Disk Pools Autoreclamation (minor clarification – storage source vs virtual disk) Removed SANsymphony cache – default settings The table that was in this section has been removed as it is now referenced in SANsymphony’s online help. For previous changes made to this document please see page 14

https://datacore.custhelp.com/app/answers/detail/a_id/838


SANsymphony’s cache

How much physical memory do I need? The following table gives a rough estimate of the amount of physical memory a DataCore Server should have installed to help plan for any current and future requirements.

Amount of physical disks in the DataCore Server (TB)

1-4 5-15 16-99 100-159 160-254 255-359 360-511 512+

Virtual Disks

5 10 50 80 128 180 250 300+

Phys. Memory

(GB) 8 16 48 96 128 256 512 1024

The values above are based on default SANsymphony cache, Disk Pool and Continuous Data Protection (CDP) History Log settings. This amount of physical memory available to the DataCore Server will determine the amount that is reserved by SANsymphony for its own caching. See Changing Cache Size: https://docs.datacore.com/SSV-WebHelp/changing_cache_size.htm

When does SANsymphony reserve memory for its cache? Whenever the SANsymphony software is started. A check is made to see how much total physical memory is in the server (or in the case of a Hyperconverged DataCore Server - the virtual machine) and, using the values above, will try to reserve physical memory for its exclusive use.

https://docs.datacore.com/SSV-WebHelp/changing_cache_size.htm

SANsymphony’s cache – How to monitor cache allocation


How to monitor SANsymphony’s cache's allocation Viewing DataCore Server object in the SANsymphony console Select the DataCore Server and using the ‘Info’ tab locate how ‘RAM’ the DataCore Server can see and how much of that has been allocated for use with SANsymphony’s cache. For example:

When the SANsymphony software is stopped, all system memory used for its cache is released back to the Windows operating system. For example:

SANsymphony’s cache – How to monitor cache allocation


Using the SANsymphony Console ‘Live Performance’ feature Select the ‘Home’ tab on the top of the Management Console and select 'Live Performance'.

In the next window select DataCore Servers from the 'Category' column and then the DataCore Server(s) from the 'Instances' column next to it. Now select 'Cache Size' from the ‘Counters’ column and click the 'Add' button.

Click the 'Done' button to display the allocated cache value.

Notes

The value displayed in the ‘Max’ column is the amount reserved by SANsymphony for its cache. The ‘Last’, ‘Average’ and ‘Min’ values should be ignored as they are misleading. During the start-up/stopping of the SANsymphony software, the allocated system memory is either gradually loaded or unloaded respectively, so depending on how fast the DataCore Server can load/unload the system memory will skew the ‘Last’, ‘Average’ and ‘Min’ values.


DataCore drivers and services

DataCore system drivers From SANsymphony version 10.0 PSP 2 and later, all DataCore system drivers (Dcs*.sys), if required, will use up to a total of 40% of the system memory already reserved by SANsymphony. This is to avoid accidentally consuming the remaining system memory, used by the Windows operating system and any other third-party applications and services, which can inadvertently make the DataCore Server unstable. However, if even more system memory is still required by the DataCore system drivers then they will also use any ‘remaining’ system memory as well. The DataCore Console and all other DataCore services (Executive, SNMP Agent, Intelligence, Performance Monitor and Updater etc.) will not use memory that has already been assigned to SANsymphony. This behavior is not configurable. Windows Task Manager and the DcsAddMem.exe process Whenever SANsymphony is started, the DcsAddMem.exe processes runs and it will begin to allocate system memory from the Windows operating system exclusively for SANsymphony’s cache – see the section ‘SANsymphony’s cache’ on page 4.

However, after the system memory has been allocated to SANsymphony’s cache, the DcsAddMem.exe will remain displayed in Windows Task Manger when actually the process is no longer running. Also, over time, the size of the memory assigned to the DcsAddMem.exe process in Task Manager may start to shrink and, in some cases, the process may disappear from Task Manager completely, even though the SANsymphony software is still running.

This does not mean that SANsymphony has less/no memory for its cache, but is simply an idiosyncrasy of how Task Manager handles the DcsAddMem.exe process once the SANsymphony software has started. Therefore, using the DcsAddMem.exe process to determine the amount of memory used by SANsymphony is not reliable. To track how much memory is really being used by SANsymphony, please see ‘How to monitor SANsymphony’s cache's allocation’ on page 5.

DataCore drivers and services


The DataCore Executive service The DataCore Executive Service provides a communication interface between all the ‘user-level’ applications and the DataCore system drivers. These applications include the SANsymphony Console, DataCore PowerShell Cmdlets, SANsymphony’s vCenter Integration and both of the DataCore Microsoft and vSphere plugins. The service is also responsible for the following:

• Monitoring and displaying Performance statistics (e.g. Live Performance, Performance Recording and Storage Allocation statistics for Disk Pools and vDisks). Also see ‘Performance Recording’ on page 10.

• Status reporting from specific DataCore system drivers for different objects in the SANsymphony Console (e.g. Mirror recovery progress, Disk Pool and Port statuses).

• Updating and distributing all configuration changes between DataCore Servers in the

same Server Group and/or remote Replication Groups.

• The transmitting of Asynchronous Replication Data to remote Replication Groups. Also see ‘Asynchronous Replication’ on page 9.

The memory requirement for this service increases the more tasks it has to perform and as the number of objects (Physical Disks, Disk Pools, virtual disks, Ports and Hosts etc.) in the configuration increases. Conversely as tasks are completed (e.g. a Performance Recording session is ended) or the configuration reduces in size (e.g. vDisks are removed This, therefore, makes it very difficult to give specific values to the amount of memory that the DataCore Executive Service will require at a given moment. There are some general ‘rules-of thumb’ that can be applied over the long-term though;

# Virtual Disks in the configuration Approximate Memory Required (GB)

1 - 20 1

50 - 100 3

500+ 5


SANsymphony features

Asynchronous Replication 8MB for each virtual disk configured as an Asynchronous Replication source. No additional memory is required for a virtual disk configured as Asynchronous Replication destination.

Continuous Data Protection (CDP) 5MB per 1GB of History Log for each CDP-enabled virtual disk.

Disk Pools

Storage Allocation Unit management The table below shows the amount of memory used for ‘typical’ amounts of physical storage and these can be used to work out the requirements for your own disk pools with different physical disk sizes.

Storage Allocation Unit size (MB)

Total Physical Disk (TB)

4 8 16 32 64 128 256 512 1024

0.5 8.75 4.36 2.19 1.09 0.55 0.27 0.14 0.07 0.03

1 17.5 8.75 4.36 2.19 1.09 0.55 0.27 0.14 0.07

5 87.5 43.75 21.88 10.94 5.47 2.73 1.37 0.68 0.34

10 175 87.5 43.75 21.88 10.94 5.47 2.73 1.37 0.68

100 - - 437.5 210.9 109.4 54.7 27.34 13.67 6.83

1024 - - - - - - 280 140 70

Notes

There is an upper limit, for each disk pool, of approximately eight million SAUs regardless of their size. The smaller the SAU size the smaller the maximum possible physical disk size a disk pool can hold before this limit is reached. Also see ‘What is the maximum Physical Storage that a Disk Pool can manage?’ https://datacore.custhelp.com/app/answers/detail/a_id/968 Example 1 A disk pool has 20TB of physical storage and a 128mb SAU size. This would require twice the amount as a disk pool with 10TB of physical storage in it i.e. 5.47 x 2 = 10.94MB Example 2 A disk pool with 7.5TB of physical storage and a 4mb SAU size. This would require 1.5 times the amount as a disk pool with 5TB of physical storage in it i.e. 87.5 x 1.5 = 131.25MB

https://datacore.custhelp.com/app/answers/detail/a_id/968



Encryption This was a new feature added in 10.0 PSP 9. Allow for double the amount of memory listed in the table above when using Encryption.

Auto-reclamation This Disk Pool function will use 200KB of system memory for each storage source managed the Disk Pool. I.e., a mirrored Virtual Disk will use 200KB of memory on each DataCore Server managing the mirror.

Manual-reclamation No additional memory is required for manual reclamation.

Inline Deduplication and Compression (ILDC) This was a new feature added in 10.0 PSP 12, it will use approximately 1.5GB of the memory already reserved by SANsymphony’s own cache, regardless of if the feature is being used or not. When configured, ILDC may consume up to a maximum of 30% of the memory reserved for SANsymphony’s own cache operations depending on the workload that the ILDC function has to perform.

Performance Recording

Live and Recorded Performance This will depend on the number of counters being recorded in the session. While a specific value of system memory required cannot be given, the overall increase is usually not significant, and the following general rule can be applied; For every 50 counters being measured, the additional memory requirement of the Executive service will increase by approximately 10%.

Historical Performance Recording Depending on the complexity of the configuration (e.g. the number of mirror port and Host mappings) the additional memory requirement of the Executive service will increase by approximately 10 – 15%.



Snapshot This will depend on the size of the virtual disk used for the snapshot source.

Virtual Disk size (GB) Memory required for each snapshot

1-127 4KB + 4KB for each additional GB

128-511 128KB + 1KB for each additional GB

512+ 128KB + 0.25KB for each additional GB

Notes:

The calculation is made for each snapshot regardless of the number of source virtual disks. Working example 1 A single virtual disk 64GB in size has five snapshots.

Each snapshot will use 4KB of memory plus an additional ‘(4 x 63) KB’ (for the size of the virtual disk source) giving a total of 256KB per snapshot. Therefore, five snapshots from a single 64GB virtual disk will use 1.3 MB of memory.

Working example 2 Six virtual disks, each 2TB in size (or 2048GB) each have one snapshot.

A snapshot for a 2TB virtual disk will use 128KB of memory plus an additional ‘((2048 – 512) x 0.25) KB’ giving a total of 512KB. Therefore, six snapshots, each from a different 2TB virtual disk, will use a 3MB of memory.



Virtual Disks

Single Virtual Disks A single virtual disk requires ~20 bytes of memory regardless of size.

Dual and Mirrored Virtual Disks This will depend on the size of the virtual disk being mirrored. Each DataCore Server managing the storage sources in a mirrored virtual disk will use the following additional memory:

Virtual Disk size (TB) Memory required

Up to 32 2MB / per TB of virtual disk size

33 - 64 1MB / per TB of virtual disk size

65 - 128 0.5MB / per TB of virtual disk size



Dynamic Data Resilient (DDR) Virtual Disks This will depend on the size of the virtual disk being mirrored. The DataCore Server acting as the ‘Parent’ for the DDR virtual disk will require slightly more memory than a dual or mirrored virtual disk as it has to maintain two in-memory bitmaps for the ‘Child’ and ‘Backup’ storage sources. The DataCore Servers acting as either the ‘Child’ or ‘Backup’ for the DDR virtual disk will continue to use the same values for mirrored virtual disks (in the previous table).

Virtual Disk size (TB) Memory required

Up to 32 3MB / per TB of virtual disk size






Third-party applications and services If during start-up other, third party applications are already using significant amount physical memory, SANsymphony may not be able to reserve as much as it expects. In this case a warning message will be posted in the SANsymphony console and the Windows System Event Log. SANsymphony will still start but will be using less than the expected amount of memory for its cache. If SANsymphony has already started and reserved memory for its own caching, no other applications running on the DataCore Server will be able to use that reserved memory, including the Windows operating system. If the Windows operating system does not have enough memory to perform its own tasks then the DataCore Server may behave erratically. Symptoms may include:

• Windows own System Event logs may report ‘insufficient memory’ warnings or errors.

• SANsymphony Disk Pool operations involving the allocation or reclamation of Storage Allocation Units (SAUs) may take significantly longer than expected or even stop working altogether.

• Historical and Performance Recording timeouts may be reported in the SANsymphony Console.

• The creation of new Asynchronous Replications may fail. The Destination Replication Server may report as being ‘Off-line’. Existing Replications that were ‘In Log’ may now report as being in ‘Standby’.

• Support Bundles may fail or take a significantly long time to complete.

• The creation of snapshots may fail and existing Snapshots may unexpectedly report as being ‘Failed’ without any obvious physical hardware problem.

• Fibre Channel and iSCSI Ports may suddenly report `being unavailable.


Previous Changes

June 2019 Added Disk Pools – Auto reclamation Virtual Disks – Mirrored and Single Dynamic Data Resiliency (DDR) Updated SANsymphony’s cache How to monitor SANsymphony’s cache's allocation SANsymphony features • Performance Recording • Snapshot • Virtual Disks - Mirrored and Single Removed SANsymphony inside a Virtual Machine This information has been moved to the document ‘Hyper-converged Virtual SAN - Deployment Best Practices’

February 2017

Added The DataCore Server's Cache - When there is not enough memory to allocate Added information about the difference in SANsymphony 10.0 PSP 5 Update 2 (and greater) Updated The DataCore Server's Cache - generally This section has been re-ordered with many of the explanations simplified.

February 2016

Updated The DataCore Server Cache - How memory is assigned to DataCore Cache Added new information for Windows Hyper-V and VMware ESXi with regard to memory settings for running SANsymphony in a Virtual Machine.

June 2015

Updated The DataCore Server Cache The previous values for the default percentages of Physical RAM allocated to the DataCore Cache driver in SANsymphony-V 10.0.0 or higher were inaccurate.

Previous (incorrect) Values Corrected Values

Available Phys. RAM % Allocated for Cache Available Phys. RAM % Allocated for Cache

4GB 50 8GB 53

5 – 48GB 65 16GB 59

49 – 96GB 75 32GB 62

97GB+ 80 64GB+ 65

Previous Changes


April 2015

Added Overview Important changes since SANsymphony-V 10.0 PSP2 Explained the new enhanced memory management behavior added in version 10.0 PSP 2

2014 and earlier

November Added Sequential Storage Added information for the new feature introduced in SANsymphony-V 10.0 PSP1 August Updated Mirrored Virtual Disks Rewrote the description of ‘The Bitmap’; and updated the table with more detailed information. July Updated How much memory do I really need? This section has been moved to the end of the document and now includes a table to be used as a ‘guide’ to determine the amount of Physical RAM that should be considered for a DataCore Server based on the amount of capacity that is being managed. June Updated The DataCore Server Cache Added values for SANsymphony-V 10.x February Added What if System Memory gets too low? Performance Recording and Support Bundles Updated The DataCore Server Cache How to find how much physical memory is in use by DataCore Cache January This document replaces DataCore’s Technical Bulletin 7b “System Memory Considerations for DataCore Servers” and contains completely updated, and rewritten, information for SANsymphony-V 9.0 PSP 4 and greater.

The authority on real-time data

Copyright © 2021 by DataCore Software Corporation. All rights reserved.

DataCore, the DataCore logo and SANsymphony are trademarks of DataCore Software Corporation. Other DataCore product or service names or logos referenced herein are trademarks of DataCore Software Corporation. All other

products, services and company names mentioned herein may be trademarks of their respective owners.

ALTHOUGH THE MATERIAL PRESENTED IN THIS DOCUMENT IS BELIEVED TO BE ACCURATE, IT IS PROVIDED “AS IS” AND USERS MUST TAKE ALL RESPONSIBILITY FOR THE USE OR APPLICATION OF THE PRODUCTS DESCRIBED AND

THE INFORMATION CONTAINED IN THIS DOCUMENT. NEITHER DATACORE NOR ITS SUPPLIERS MAKE ANY EXPRESS OR IMPLIED REPRESENTATION, WARRANTY OR ENDORSEMENT REGARDING, AND SHALL HAVE NO

LIABILITY FOR, THE USE OR APPLICATION OF ANY DATACORE OR THIRD PARTY PRODUCTS OR THE OTHER INFORMATION REFERRED TO IN THIS DOCUMENT. ALL SUCH WARRANTIES (INCLUDING ANY IMPLIED

WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE AND AGAINST HIDDEN DEFECTS) AND LIABILITY ARE HEREBY DISCLAIMED TO THE FULLEST EXTENT PERMITTED BY LAW.

No part of this document may be copied, reproduced, translated or reduced to any electronic medium or machine-

readable form without the prior written consent of DataCore Software Corporation

the datacore server

Documents