insync deployment and scalability best practices - druva

13
inSync Deployment and Scalability Best Practices www.druva.com

Upload: others

Post on 16-Mar-2022

4 views

Category:

Documents


0 download

TRANSCRIPT

inSync Deployment and Scalability

Best Practices

www.druva.com

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

* * *