Looking for:
Windows server standard support failover cluster free - دکتر راحله صادقی. |
Microsoft Failover Cluster Manager (MSFCM) on Windows server /.
With the arrival of SQL Server , customers enthusiastically welcomed the introduction of Basic Availability Groups in Standard Edition — a feature that is set to replace the now deprecated Database Mirroring feature. This provides an opportunity to enable cost-effective high availability and disaster recovery solution for mission-critical databases without the need for an expensive Enterprise Edition license. However, this also introduces confusion among customers who now have to make the decision to choose between implementing Failover Cluster Instances FCI or Basic Availability Groups.
This confusion can lead to unnecessary hardware, deployment and operations costs that can make the licensing cost seem irrelevant. When SQL Server was released, licensing was made available on a per-core basis. Prior to SQL Server , the goal was to buy processors with as many cores as possible in order to maximize the overall processor performance per processor license.
This practice became disadvantageous with the core-based licensing model, particularly with SQL Server Enterprise Edition. Core-based licensing required a minimum of four 4 core licenses per processor which are sold in packs of two 2 , where each SKU covers two processors.
Using the core-based licensing model, if you have a dual-core, dual-processor machine — a total of four 4 cores — to run SQL Server and higher versions, you would need to purchase four SQL Server core license SKUs to cover eight 8 cores despite only having a total of four 4 cores. SQL Server introduced yet another change in licensing: the right to install and run an SQL Server instance as a passive failover has become a Software Assurance benefit.
If you are running a log shipping secondary, a database mirroring partner, a standby node in an FCI or a secondary replica in an Availability Group, you must purchase Software Assurance to get them licensed. These changes in the SQL Server licensing model have created a major trend in data center management to minimize cost: an increase in virtualized and consolidated environments.
Customers provision a high-end physical server, having processors with as many cores as possible, and license all of the cores with an SQL Server Enterprise Edition license plus Software Assurance. While virtualization and consolidation somehow reduced SQL Server licensing costs, it increased management overhead and bypassed the need for more granular recovery objectives and service level agreements.
Every SQL Server virtual machine deployed on the physical host was treated the same regardless of recovery objectives and service level agreements. And while the underlying physical host can be protected by means of failover clustering, the SQL Server virtual machines are not.
A powered down virtual machine due to a blue screen can be offline for an extended period of time. Customers running an FCI continued to maintain their existing infrastructure and upgraded to later versions as appropriate. However, those running Database Mirroring were faced with the challenge of upgrading especially when the principal and the mirror SQL Server instances are running Standard Edition.
The dilemma: either postpone the upgrade and run the risk of being in an unsupported configuration or make the leap and upgrade to Enterprise Edition. These changes in licensing and new features made it very clear that Microsoft really does want customers to move towards Enterprise Edition. But unlike its Enterprise Edition counterpart, there are some limitations. You cannot enable the secondary replica as a readable secondary. This is the same as Database Mirroring in Standard Edition.
If you want to enable the secondary replica or mirror partner in Database Mirroring for reporting workloads, you need Enterprise Edition. No is the only option when you click on the drop-down list under the Readable Secondary column in the Specify Replicas page of the New Availability Group Wizard. While there are limitations, there are also advantages when you compare them with Database Mirroring in Standard Edition. Understanding the benefits and limitations of Basic Availability Groups can give you enough information to decide whether you would like to still use Database Mirroring regardless of its deprecation status or upgrade to Enterprise Edition to take advantage of all the Availability Group features.
However, both options still put you at a disadvantage — the former being at the risk of using an unmaintained feature, the latter being more expensive. This feature is not new and has been around since SQL Server 6. Highlighted below are the differences between the two that can help you make the right decision in choosing the appropriate high availability solution.
While the comparisons apply to traditional Availability Groups as well, the focus will be on Basic Availability Groups. A database is an object that resides within an instance. Understanding the difference between an instance and a database can help make decisions in implementing the appropriate high availability solution in terms of operational efficiency. In an FCI, the entire instance is protected. If the primary node becomes unavailable, the entire instance is moved to the standby node.
These instance-level objects are stored in the system databases which are physically stored in shared storage. In an Availability Group — be it the traditional or basic — only the databases in the group are protected. System databases cannot be added to an Availability Group — only user databases are allowed. If all the dependent system objects are not replicated on all replicas, the database may end up becoming inaccessible to the application; as in the case of missing SQL Server logins or partially functional as in the case of missing certificates for Always Encrypted SQL Server Service Pack 1 made Always Encrypted available in Standard Edition.
If you are more concerned with instance-level protection to minimize possible human error during change management processes, then, an FCI is the way to go. An FCI requires some form of shared storage. The shared storage is accessible to all of the nodes in the failover cluster but only the current primary node has ownership at any given point in time. The system and user databases are stored on the shared storage. When a failover occurs, ownership of the shared storage moves from the current primary to the standby, making the databases available to the new primary node.
From a capacity point-of-view, you only need to provision disk space based on the sizes of the databases. However, from an availability point-of-view, the shared storage becomes a single point of failure.
The FCI will remain offline if the shared storage becomes unavailable, regardless of the number of nodes in the failover cluster. An Availability Group does not require shared storage.
Each replica has its own local storage independent of the Availability Group. If the primary replica becomes unavailable and a failover occurs, any secondary replica can take over without having to rely on the availability of the system and user databases from the primary replica. From a capacity point-of-view, you need to provision disk space based on the sizes of the databases and the number of secondary replicas, significantly increasing the cost per gigabyte.
But from an availability point-of-view, because the Availability Group replicas do not rely on a single storage source, the SQL Server instance hosting the replicas remains online regardless of what happens to the primary replica. Each Availability Group replica has its own copy of the system databases, thus, it is always online regardless of whether it is functioning as a primary or a secondary replica.
The complexities of a shared storage subsystem like a storage area network SAN require the proper administration to guarantee high availability and resiliency because the storage becomes a single point of failure. You may have certain disaster recovery requirements to have multiple copies of your databases. Because of the shared storage requirement, an FCI will only have a single copy of the databases. If you need multiple copies of your databases, you will need to implement either log shipping, database mirroring or Availability Group together with the FCI.
This requires additional cost in terms of licensing and administrative overhead. Not so with Availability Groups. The standby server is only covered by a license if it comes with Software Assurance. Assume that you will only run a single instance FCI in a 2-node failover cluster and two replicas in a Basic Availability Group.
One might think that a single Standard Edition license with Software Assurance will cover both servers. This is true in the case of an FCI. Since you only have a single FCI, it can only be available on one of the failover cluster nodes at any given point in time. You cannot run the same FCI on all of the failover cluster nodes at the same time. In an FCI, the standby node acts as a true standby server.
In an Availability Group, since all of the replicas are online and available at any given point in time, there is a possibility of running multiple Availability Groups simultaneously on any of the replicas. This is specifically true in Basic Availability Groups where you will have multiple Availability Groups, one per database. Because an Availability Group exists as a resource group in a failover cluster, it can run on any of the available replicas.
This does not become a licensing issue if you only have one Basic Availability Group. Thus, requiring more than one Basic Availability Group. In almost all cases, the failover cluster will move all of the Basic Availability Groups together when a failover occurs.
However, there will be rare cases where one Basic Availability Group might end up in a different replica than the rest, for example, initiating a manual failover of one of the Basic Availability Groups or a failover policy that automatically moves a Basic Availability Group from one replica to another. When this happens, you need to define a process on how to keep all of the Basic Availability Groups running on the same replica to avoid being in violation of your licensing agreement.
There could be cases where you would need instance-level protection, multiple copies of your databases and a guaranteed true standby server while minimizing licensing costs. The reference diagram below describes this architecture. All three 3 servers are nodes in the same failover cluster. The FCI provides instance-level protection for local high availability, guaranteeing a true standby server, while the Basic Availability Group provides the extra copy of the databases for disaster recovery purposes.
But with all of the features available, choosing the right solution can become daunting and confusing. What is Software-Defined Storage? Why All-Flash Exactly? Book Free Online Demo:. First Name. Last Name. Job Title. Corporate Email. Phone Number. You agree that StarWind Software Inc. You can withdraw your consent at any time by reaching us at dataprotection starwind.
For more information on how we process your personal data, please read our Privacy Policy. Thank you for your application!
No comments:
Post a Comment