Sql-server – Clustering SSAS

Nismo,

It's not the SIZE of the database that matters (no jokes intended), it's the rate of change coupled with the infrastructure available. For example, a relatively static database might perform poorly on 1Gb connection on an overloaded switch with 5400 RPM sata drives.

If the rate of change (aka look at your log flush bytes) is less than around 200 MB/sec and you have very fast storage (or a ton of front end cache) and extremely low latency networking then I would say you'll be fine.

Let's go over your questions now:

1.Is this size okay for Availability Groups (we are looking to have 2-3 replicas)?

It's not about the size, but the infrastructure. So, yes that's fine.

2.If network dies for 1hour, how fast can we get the replica in sync?

How fast does an unladened swallow fly? Seriously though, there is no way for us to tell you. You'll need to take into account the rate of log generation + latency + blocked redo + sync/async status.

The better question to ask is, "Do I have enough space on my primary for my transaction log to NOT TRUNCATE for an hour?"

3.Do you guys have any consideration I should be following before using Availability Groups?

I would consider taking a serious look at SQL 2016 if these are your concerns. Parallel redo (coming soon), better network utilization, distributed AGs, direct seeding, etc.

If you're intent on using 2014, then the best recommendation is to make sure the server hardware and infrastructure are up to the rate of change you'll be creating. Additionally watch when you do DDL against objects as it could pose potential problems with redo.

If you're worried about the replicas catching up in time, just remove the replicas from the AG, restore the transaction logs to them and then bring them back into the AG. Remember, your primary won't be able to have the log file re-use any VLFs while an AG is "behind" as it'll only be able to mark for re-use up to that LSN.

Always On is not synonymous with (Always On) Availability Groups and instead is more a marketing term to describe a suite of Microsoft High Availability technologies (which I argue is at best ambiguous). The term actually started out as "Always On" (note the space) a long time ago as a pure marketing term (see my graphic as an example), but with the release of SQL Server 2012 was adopted as a wider catch all replacement marketing name for what they called "Hadron" during development (which was specifically Availability Groups) and several other HADR technologies (such as SQL Failover Clustering). The only difference was that when the term was first used, it did not have the trailing space (i.e. "AlwaysOn"). Marketing in their infinite wisdom have now added a space back into the term to add even more confusion :).

The bottom line is that if you completely ignore the use of the term AlwaysOn/ Always On and explicitly refer to the technology Availability Groups/ Failover Clustering/ Database Mirroring etc (or ask people to clarify which technology they are referring to) then you cannot go far wrong.