Suggested Topology - Suggestions Welcome!

[mrrodge]

Hi all,

Been a lurker on and off for a few months and have had a go with the trial (it's great). I'm not actually looking to put into production yet as we haven't nailed down our new hardware setup. We're currently not virtualised and run a single server with multiple roles and old-school backup (Acronis).

We're looking to build our main server (fast storage, loads of RAM for production use) and a slower (less RAM and slower storage) 'limp server' in the same cabinet for replication/planned and unplanned failover. We can tolerate some downtime so we reckon replication can occur every 30 minutes or so (hence not opting for failover clusering/HA and the associated cost). A virtual drive on the limp server (possibly an iSCSI target, not sure yet) will also serve as our on-site backup and we'll have a NAS in a nearby building serving as our iSCSI offsite backup. We also have a third hyper-v host running just a single VM at present for our firewall, but in fairness it could host another couple of light-load VMs if necessary.

We have on-prem Exchange, AD, SQL, File Server and a few Linux VMs such as PBX system, Rocket.Chat etc.

All of our hardware is existing (we don't need to purchase any, or at least we don't think) and we're cobbling together what we can.

Main Server

• Dual Xeon E5-2620 v4 with 128GB RAM

• Small SSD for host OS

• Dual mirrored SSDs for Exchange/High IOPS/random stuff

• Dual NVMe SSDs for cache on main storage array

• 4x mechanical drives for main file storage in RAID10, supplemented by cache above

Limp Server

• Dual Xeon E5-2620 v3 with 64GB RAM

• Storage almost same arrangement with possibly more SSD cached mechanical drives for backup and no SSD volume for exchange/SQL

Firewall hypervisor

• Slow Pentium Dual Core with SSD and 8GB DDR3, more or less desktop spec.

Queries as follows:

• Which physical machine would you put the backup server on? Production, limp or firewall?

• Would you run it in a VM?

• Same two questions for the database - with the backup server or on our SQL server?

• I gather VEEAM now backs up its config to the backup repos by default now, so a fresh install and settings import would be possible if the site was lost along with both the production machine and the limp machine.

My thoughts were to run it on the limp server's host directly, so data is 'pulled' from the production server and failover can be initiated in the case of production hardware failure. I'm saying directly on the host purely because it'll save me a precious GB of RAM.

The next one is more of a general query:

How do you guys use VEEAM with your archiving solution? We don't yet have anything for data archiving but would primarily like to get data off the costly storage and onto cheaper storage. We were looking at using the in-place archive for Exchange and having the archive database on mechanical storage to keep the primary database small. We have no idea where to go with it for files but are considering just using the backups. Any suggestions?

Thanks, and sorry for the lengthy post!

[Mike Resseler]

Hey Joseph,
Welcome to the forums with your first post

I can't give you any specific feedback on the hardware, I will leave that to others but I will answer a few of your questions

Which physical machine would you put the backup server on? Production, limp or firewall?

With your setup, I would run it in a VM to be honest.

Would you run it in a VM?

Yes

Same two questions for the database - with the backup server or on our SQL server?

With your environment, the SQL embedded with Veeam Backup Server should be more than enough

I gather VEEAM now backs up its config to the backup repos by default now, so a fresh install and settings import would be possible if the site was lost along with both the production machine and the limp machine.

See here: https://helpcenter.veeam.com/docs/backu ... tml?ver=95


For your last question. Did you mean archiving data off to a tape or cloud or so? Or are you asking what to do with the Exchange archive?

[mrrodge]

Hi there,

Many thanks for the quick reply!

On the archiving, we're talking in general, both for files and Exchange.

I was thinking the Exchange archive database could go on the mechanical array, but what's the activity going to be like, assuming it's hardly accessed by clients? Will it cripple my file server with IOPS even though clients will hardly access it? Fairly new to Exchange and not sure on the database maintenance etc.

For files, really not sure which way to go. Was thinking of just using the backups for archive purposes and running an FSRM script or similar to delete expired files. Does anyone else do this, or should we be looking at something proprietary?

Thanks again.

[Mike Resseler]

Joseph,
(Sorry for the late reply, overlooked this one, mea culpa).

Exchange has a built-in archive solution (which is limited for some, but enough for others). Purely from an IOPS perspective I wouldn't worry about it. There is going to be some IO because it needs to move "production" items to the archive database. Mostly it will even be advised to put the archive db on slower storage to save on costs.

For files, there are also options. If you use the backups for archive purposes (which is possible) mostly you will see that older files are not being deleted unless you indeed use a script. There is special software on the market for it, but probably out of your budget. A script could work, but then look at modified/ accessed date and not on creation date

[mrrodge]

Sorry for my late reply!

Great feedback and much appreciated.