insync deployment and scalability best practices - druva
TRANSCRIPT
Page 2
inSync Deployment and Scalability Best Practices
Table of Contents
Deployment & Scalability Best Practices ........................................................ 3
inSyncServer Requirements ............................................................................................... 3
Storage/Disk Related Recommendations .......................................................................... 4
Planning Storage Size ......................................................................................................... 4
Storage Recommendations ................................................................................................ 5
Disk Type/RAID Recommendations .................................................................................... 7
Operating System Recommendation ................................................................................. 7
inSync Client Mass Deployment Best Practices ................................................................. 7
inSync User Mass Deployment Best Practices ................................................................... 7
a. AD Import ................................................................................................................. 7
b. CSV Import ............................................................................................................... 7
c. Mass Token-based deployment ............................................................................... 8
d. Silent Key loading from command line .................................................................... 8
inSyncUser Profile Best Practices ....................................................................................... 8
Microsft Outlook Advanced Syncing .................................................................................. 8
Large File Optimization ....................................................................................................... 9
Profiling Users .................................................................................................................... 9
Backup Schedule ................................................................................................................. 9
Resources ......................................................................................................................... 10
High ScalabilityScenario Tests .......................................................................................... 11
Hardware Benchmarking Tests......................................................................................... 12
Appendix ..................................................................................................... 13
Must Read KB articles ....................................................................................................... 13
DR (Disaster Recovery) Best Practices- Weekly Backup of Druva inSyncServer .............. 13
Additional Resources ........................................................................................................ 13
Page 3
inSync Deployment and Scalability Best Practices
Deployment & Scalability Best Practices
This document offers best practices for deploying inSync Enterprise for a wide range of
users and data. It also offers best practices on high-end scalability with the goal of
maximizing the number of users on a single Enterprise server.
iinnSSyynncc SSeerrvveerr RReeqquuiirreemmeennttss
The following table specifies the server requirements for your deployment:
Users <=1,000 <= 2,000 <= 5,000 <= 10,000
CPU Quad/ Six Core Xeon
Quad / Six Core Xeon
2-socket Quad / Six Core Xeon
2-socket Quad / Six Core Xeon
RAM 12 GB 16 GB 32 GB 64 GB
Data 4.8 TB 9 TB 24 TB 48 TB
The data component can be hosted on a RAID 5 array of minimum 7.2 K SATA drives
Database (DB) ~350 GB 600–800 GB 1.4–1.8 TB 5 TB
The DB has to be hosted on RAID 1+0 array of 15k SAS drives.
SIS Database ~250 GB 450-600 GB 800 GB – 1 TB 1.5 TB
SIS can be stored on a single SSD or a RAID 1 array
DB logs 20 GB 20 GB 20 GB 20 GB
The DB logs can be hosted on RAID 1 configuration comprising SATA/SAS drives.
Network 1 Gbps 1 Gbps 1 Gbps 1 Gbps
Total Disk Space ~5.4 TB ~10 TB ~27 TB ~55 TB
Page 4
inSync Deployment and Scalability Best Practices
Notes:
1. inSync storage includes the following components:
a. Data – The backup data space created under the “Data folder” configuration of storage.
b. DB – The storage database created under the “Database folder” configuration of the storage.
c. DB Logs – Database Logs created under the “Database log folder” configuration of the storage.
2. To get the best performance, we recommend configuring the SIS Database on SSD disks. SSD disks give you almost an 8x performance improvement compared to SATA disks as SSDs improve the random read performance.
3. SSD’s are recommended only for deployments larger than 1,000 users. Please see the benchmarking section for SSD vs HDD performance numbers for details.
4. The above-mentioned requirements for memory are the minimum required. Memory requirements will change depending upon your storage size. It is recommended to have 4 GB of RAM per 1 TB of storage.
5. Exact disk space requirement for "Data" and "DB" depends upon the amount of data captured from each user. Please refer to the general disk-related guidelines for more details.
6. In the above table, disk space requirements are calculated for upper limit of users in each section (Please check each section for the same) and for 20 GB of average data per user. Retention policy of 15 days with daily % data change per user is 5%. Use the ROI calculator (http://www.druva.com/insync/roi-calculator) for disk space requirements specific to your setup.
SSttoorraaggee//DDiisskk RReellaatteedd RReeccoommmmeennddaattiioonnss
PPllaannnniinngg SSttoorraaggee SSiizzee
1. For deployments of more than 250 users, please use an additional dedicated volume for
the DB Logs (described later).
2. For the exact disk space requirements for storing backup data, please refer to the
ROI Calculator on the website - http://www.druva.com/insync/roi-calculator
3. Size of database “DB” folder varies between 10-15% of the backed up data, i.e., "Data"
folder.
4. A minimum free disk space is mandatory on the volume containing database
and database log directories. This is necessary to prevent database corruption in out-of-
Page 5
inSync Deployment and Scalability Best Practices
disk conditions. As a default, this value is set to 4 GB per directory (database and
database log). This value is separate and not shared. For example, if both database and
database log directories are on the same drive/volume, then a minimum 8 GB free disk
space is required. Each drive should have a free space of at least 4 GB if Database
and Database Logs are configured on separate drives.
5. If the backups are configured for BMR (Bare Metal Restore), it is highly recommended
that you use separate disks for “Data” and “DB”.
6. It is very important to exclude backup folders from live anti-virus scan/on access scan.
Most antivirus products lock files frequently, which may cause database corruption.
When data is uploaded to the data folder, references for actual data are stored under
database files. If the anti-virus product locks database files, inSync may not be able to
update database files and could lose some of the references. Hence it is recommended
to exclude the following directories from anti-virus scan:
C:\inSyncServer4
C:\Program Files\Druva
Storage-bases folders for all configured inSync storages
o Storage Data folder
o Storage Database folder
o Storage Database log folder
SSttoorraaggee RReeccoommmmeennddaattiioonnss
1. InSync supports DAS, SAN and NAS storage devices. Please choose disks with 300 Mbps
(SATAII) for better read/write throughput.
2. NAS is supported but not recommended because of possible latencies and throughput
restrictions imposed by the network, which may cause performance issues.
3. “Maximum parallel connections” to inSync storage defines the upper limit for
parallel backup or restore operations that can be performed by the particular storage.
By default, this value is set to 20 concurrent connections. In general, you can set it to 10
% of total users hosted on the inSync server.
4. SSD’s are strongly recommended only in deployments of 1,000 users or more. Please
see the benchmarking sample graph section for SSD vs. HDD performance numbers.
Page 6
inSync Deployment and Scalability Best Practices
5. HyperCache requirements: HyperCache is anin-memory cache of deduplication indexes
that maximizes the performance of the storage. Traditionally, these deduplication
indexes are maintained in the database on HDD, which become slower as the database
grows in size. The HyperCache innovation ensures that the most referenced
deduplication indexes are maintained in memory (RAM) for quick access to give a boost
to backup performance. HyperCache can be configured on inSync Enterprise and can
be fine-tuned for optimal performance. It’s recommended to configure a 4GB
HyperCache size for every 1TB of storage. For example, for a storage size of 2TB, it is
recommended to configure HyperCache as 8192 MB. Also, HyperCache should not
exceeded 50% of the total RAM.
6. Storage Optimization Configuration: Under the Storage Advanced tab, refer to the
setting that allows us to configure either for Optimize for Network Bandwidth or
Optimize for Backup Speed. Here, select the configuration option Optimize for Backup
Speed.
Page 7
inSync Deployment and Scalability Best Practices
DDiisskk TTyyppee//RRAAIIDD RReeccoommmmeennddaattiioonnss
1. SSDs (Solid Sate Drives): To get the best performance, we recommend configuring the
SIS Database on SSD disks. SSD disks give you almost 8x performance improvement
compared to SATA disks as SSDs improve the random read performance. Storage
creation has an option to configure SIS DB on SSD volume. You can find this option under
the “Druva InSync Server Web Control Panel -- Configuration -- Storage -- Create New
Storage -- Performance -- Path of SSD storage. The SIS Database requirement is generally
50 GB for 1 TB of Storage Data folder.
2. RAID 5 or 6 is NOT recommended for the database volume due to the fact that the
database workload generates lots of random writes, which perform poorly on RAID5.
Hence, RAID 5 or 6 is strongly discouraged for high-performance DB environments.
OOppeerraattiinngg SSyysstteemm RReeccoommmmeennddaattiioonn
Recommended OS for Servers: Windows 2008 R2 server
iinnSSyynncc CClliieenntt MMaassss DDeeppllooyymmeenntt BBeesstt PPrraaccttiicceess
The inSync client is an MSI package that can be deployed using any third party tool like GPO,
SCCM or LANDesk. A basic KB article listing the similar steps using Active Directory GPO can
be read here.
iinnSSyynncc UUsseerr MMaassss DDeeppllooyymmeenntt BBeesstt PPrraaccttiicceess
Once you have the inSync client/agent installed on endpoint devices, you willneed to create
new users and mass deploy the user authentication key. This can be done in the following
ways:
aa.. AADD IImmppoorrtt
inSync supports importing users from Active Directory.For AD user importfunctionality, refer
to the Druva inSync Server Administrator Guide section 3.3.3.2 Import Users.
bb.. CCSSVV IImmppoorrtt
You can also import users into inSync via a CSV file. In the inSync Server Administration
Guide refer to the section 3.3.3.2 Import Users.
Page 8
inSync Deployment and Scalability Best Practices
cc.. MMaassss TTookkeenn--bbaasseedd ddeeppllooyymmeenntt
For information on this feature, please refer to the Druva inSync Server Administrator Guide
section Mass Deployment Token.
dd.. SSiilleenntt KKeeyy llooaaddiinngg ffrroomm ccoommmmaanndd lliinnee
For details on silent key loading from the command line, kindly refer to the following KB
article that lists the steps here.
iinnSSyynncc UUsseerr PPrrooffiillee BBeesstt PPrraaccttiicceess
inSync administrators can benefit from the following best practices on user profiles and
policies:
MMiiccrroossoofftt OOuuttllooookk AAddvvaanncceedd SSyynncciinngg
inSync offers two ways to backup Microsoft Outlook PST files. The traditional method of
backup using block based deduplication technique backs up the file using VSS snapshots.
The accuracy here is limited. The more accurate and performance-oriented method is to
backup using inSync’s application-aware deduplication feature, which understands the on-
disk format of applications to offer better deduplication.
Key benefits include:
Faster Deduplication: “App-aware” eliminates dependence on multiple checksums
100% Accurate: Understands application formats
Designed for Laptops: Support for applications like Microsoft Outlook/Office, PDF and
Images.
Page 9
inSync Deployment and Scalability Best Practices
LLaarrggee FFiillee OOppttiimmiizzaattiioonn
We recommend that folders with more than 10,000 files (large number of small files) be
backed up using the “LFO” setting, enabled while configuring the folder for backup.
PPrrooffiilliinngg UUsseerrss
An inSync user profile is one of the most important parts of the configuration. The following
are some recommendations for setting up the User Profile -
BBaacckkuupp SScchheedduullee
The following diagram shows the backup schedule settings.
Synchronization Interval – This should be chosen as per your backup need. It is
recommended to choose 8 hours as an interval.
Page 10
inSync Deployment and Scalability Best Practices
User control – Unless the users are technical and you wish them to manage their own
backup schedules, it’s recommended to disallow them to change the schedule or pause
the backups.
Backup Interval – It is highly recommended to choose different backup intervals for
different user profiles. This distributes the server load and helps in resource
management. For example, you may allow your local users to synchronize first in the
morning and the remote users to synchronize later in the afternoon. As a result,your
server load is distributed and you can save on backup time and bandwidth.
RReessoouurrcceess
The following diagrams show the bandwidth and restore settings.
CPU Priority - If set between 5 to 10, then the inSync client backup process is prioritized
higher than other active applications. If the CPU priority is set below 5, the backup
process will be slowed down to reduce CPU consumption. It is recommended that you
set CPU priority at 4 for incremental backups.
Bandwidth – It is highly recommended to limit the bandwidth usage for each profile.
Administrator can set a percentage or an absolute value as a limit on each incoming
connection.
Retention Policy –The retention policy may vary depending on your organization’s data
protection needs, however '30 days' is the most commonly used.
Note: Higher retention policy demands more storage space. Please refer to the ROI
calculator to compute the exact storage requirements based on your retention policy.
Page 11
inSync Deployment and Scalability Best Practices
HHiigghh SSccaallaabbiilliittyy SScceennaarriioo TTeessttss
Druva has conducted comprehensive high scalability tests for inSync.
The tests were conducted for over 7+ TB of data with a 1:2 dedupe ratio. During the test,
multiple user syncs were happening concurrently, each with 20 GB per user data. The user
data consisted of emails and documents. We observed a sustained 40 MB/sec sync speed on
the server.
The sync rate and data rate are shown in the graph below.
Through the initial phase of the tests, the sync rate and data rate stayed very close.
Although, as tests progressed, we observed more than 2x improvements in the sync rate
and gradual decrease in the data rate due to deduplication factor.
0100002000030000400005000060000700008000090000
100000110000120000130000140000150000160000170000180000190000200000210000
10
:37
PM
10
:54
PM
11
:11
PM
11
:27
PM
11
:44
PM
12
:00
AM
12
:17
AM
12
:33
AM
12
:49
AM
1:0
6 A
M
1:2
2 A
M
1:3
9 A
M
1:5
5 A
M
2:1
5 A
M
2:3
6 A
M
2:5
6 A
M
3:1
6 A
M
3:3
6 A
M
3:5
6 A
M
4:4
9 A
M
5:1
5 A
M
5:3
5 A
M
6:0
0 A
M
6:2
2 A
M
6:4
6 A
M
7:0
7 A
M
7:2
6 A
M
7:4
5 A
M
8:0
2 A
M
8:2
0 A
M
8:3
8 A
M
8:5
6 A
M
Sync Rate
Data Rate
Page 12
inSync Deployment and Scalability Best Practices
The hardware used for this purpose was as follows:
CPU: -Socket 6 Core Xeon Server
RAM: 32 GB
Data: On an industry standard SAN box with RAID 5 array of 12 disks.
DB: On RAID 10 array of SAS disks.
SIS: On RAID 0 SSD array.
HHaarrddwwaarree BBeenncchhmmaarrkkiinngg TTeessttss
To benchmark the hardware used, we ran tests using Microsoft tool known as SQLIO. The
LUN’s that have been benchmarked are Data, DB and SIS. These tests were executed on
RAW storage volumes and are at a micro level.
Note: Please note that disabling caching resulted in better IOPs numbers.
Page 13
inSync Deployment and Scalability Best Practices
Appendix
MMuusstt RReeaadd KKBB aarrttiicclleess
Druva InSync - Recommendations, Best Practices, Tips and Tricks
Technical FAQ
DDRR ((DDiissaasstteerr RReeccoovveerryy)) BBeesstt PPrraaccttiicceess-- WWeeeekkllyy BBaacckkuupp
ooff DDrruuvvaa iinnSSyynncc SSeerrvveerr
For disaster recovery, Druva InSync Server must be backed up at least once a week. The
Server can be backed up using any tool that supports VSS, security settings, junction points
and volume mount points. For a detailed explanation of backing up the server using
NTBackup, please go through the following KB article: Archival and Restore of InSync Server
Using Microsoft NTBackup
AAddddiittiioonnaall RReessoouurrcceess
Druva Forums
Knowledge Base
Support Portal
* * *