Thursday, November 29, 2007
Wednesday, November 28, 2007
SQL always on and MSSRA Windows Server System Reference Architecture
Failover Clustering
Failover Clustering provides server-level redundancy on a certified Microsoft
Cluster Services configuration. The shared disk array is configured to allow all
nodes access to the disk resources with only one node actively processing.
When the server node fails, the failover cluster automatically moves the control of the shared resources to a working node and restarts SQL Server.
This configuration allows seamless failover capabilities in the event of a CPU, memory or other non-storage hardware failures.
Geographically Dispersed Failover Clustering
Geographically Dispersed Failover Clustering provides server-level redundancy on a certified Microsoft Geographically Dispersed Cluster Services configuration with one or more storage array at each site. If the site, the server node or the disks fail, the complete system and disk redundancy allows the failover cluster to handle sequent activities on the working site. This configuration removes the single-point of failure potential in a typical failover cluster configuration.
http://www.microsoft.com/sql/alwayson/overview.mspx
http://download.microsoft.com/download/d/4/c/d4cc681a-d51c-4f69-8c89-1198bee335d2/SQLServerAlwaysOnBrochure.pdf
http://www.databasejournal.com/features/mssql/article.php/3456991
These data stores do not need to be part of either the OLTP or the data warehouse environments because they are not mission critical. To prevent the data stores from affecting the performance and reliability of the other data service environments, the data stores exist on separate servers. While the data store databases do not have the same mission critical requirement as the OLTP environment, a level of availability ensures continued processing in the event of failure.
Database mirroring enables a level of availability without the hardware requirements of a separate failover cluster. The use of multiple instances has a number of benefits, one of which is the ability to make performance-tuning configuration on an
instance-by-instance basis. This enables control of the environments resource usage into the future as the data services requirement grows.
OLTP, OLAP , Data Warehouse, Data Stores, and Extranet.
Failover Clustering provides server-level redundancy on a certified Microsoft
Cluster Services configuration. The shared disk array is configured to allow all
nodes access to the disk resources with only one node actively processing.
When the server node fails, the failover cluster automatically moves the control of the shared resources to a working node and restarts SQL Server.
This configuration allows seamless failover capabilities in the event of a CPU, memory or other non-storage hardware failures.
Geographically Dispersed Failover Clustering
Geographically Dispersed Failover Clustering provides server-level redundancy on a certified Microsoft Geographically Dispersed Cluster Services configuration with one or more storage array at each site. If the site, the server node or the disks fail, the complete system and disk redundancy allows the failover cluster to handle sequent activities on the working site. This configuration removes the single-point of failure potential in a typical failover cluster configuration.
http://www.microsoft.com/sql/alwayson/overview.mspx
http://download.microsoft.com/download/d/4/c/d4cc681a-d51c-4f69-8c89-1198bee335d2/SQLServerAlwaysOnBrochure.pdf
http://www.databasejournal.com/features/mssql/article.php/3456991
These data stores do not need to be part of either the OLTP or the data warehouse environments because they are not mission critical. To prevent the data stores from affecting the performance and reliability of the other data service environments, the data stores exist on separate servers. While the data store databases do not have the same mission critical requirement as the OLTP environment, a level of availability ensures continued processing in the event of failure.
Database mirroring enables a level of availability without the hardware requirements of a separate failover cluster. The use of multiple instances has a number of benefits, one of which is the ability to make performance-tuning configuration on an
instance-by-instance basis. This enables control of the environments resource usage into the future as the data services requirement grows.
OLTP, OLAP , Data Warehouse, Data Stores, and Extranet.
Sunday, November 25, 2007
VMware Infrastructure 3 QLogic QDepth
By default, VMware Infrastructure 3 uses the QLogic QDepth default value of 32 to act as an execution throttle. As a best practice, QDepth should be limited to around eight to retain some headroom for expansion. Refer to VMware Knowledge Base article 1267 on how to adjust the QDepth for performance tuning. In general, the following formula applies to each path between the host machine and the array: [Total number of LUNs] * QDepth < [Array queue depth] Refer to VMware Knowledge Base article #1267 at www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=1267 for more information on tuning QDepth. • The default queue depth value of 32 is satisfactory for Emulex HBA cards. • If you are using Microsoft® Windows® 2000 or Windows Server 2003 check your operating system timeout values. For a VMware environment, the DiskTimeOutValue must be set to 60 seconds. • Dynamic load balancing is currently not supported by VMware Infrastructure 3. However, for active/active arrays with fixed failover policy, load balancing can be achieved by manually assigning a LUN to a specific path. For more information, refer to the VMware document, “Server Configuration Guide,” at http://www.vmware.com/pdf/vi3_server_config.pdf.
HP StorageWorks EVA - ESX
SAN Configuration Guide : Setting Up SAN Storage Devices with ESX Server : HP StorageWorks Storage Systems : HP StorageWorks EVA
HP StorageWorks EVA
HP StorageWorks EVA
NUMA systems
ESX Optimization for NUMA systems
Many of the interesting new hardware systems today are implemented using non-uniform memory architectures. This means that not all memory is of uniform speed – accessing memory that is closer topologically to the processor is faster than memory that is further away.
To ensure optimal performance, the VMware ESX hypervisor allocates memory for the guest operating systems from physical memory near the CPU on which the guest resides on.
Many of the interesting new hardware systems today are implemented using non-uniform memory architectures. This means that not all memory is of uniform speed – accessing memory that is closer topologically to the processor is faster than memory that is further away.
To ensure optimal performance, the VMware ESX hypervisor allocates memory for the guest operating systems from physical memory near the CPU on which the guest resides on.
SQL 2005 Database Mirroring and Log Shipping
SQL Server 2005 Books Online (September 2007)
Database Mirroring and Log Shipping
A given database can be mirrored or log shipped; it can also be simultaneously mirrored and log shipped. To choose what approach to use, consider the following:
How many destination servers do you require?If you require only a single destination database, database mirroring is the recommended solution. If you require more than one destination database, you need to use log shipping, either alone or with database mirroring. Combining these approaches gives you the benefits of database mirroring along with the support for multiple destinations provided by log shipping.
If you need to delay restoring log on the destination database (typically, to protect against logical errors), use log shipping, alone or with database mirroring.
This topic discusses considerations for combining log shipping and database mirroring.
SQL 2005 Database Mirroring and Log Shipping
Setting Up Mirroring and Log Shipping Together
Setting Up Mirroring and Log Shipping Together
To set up database mirroring and log shipping together, the following steps are required:
Restore backups of the principal/primary database with NORECOVERY onto another server instance to be later used as database mirroring mirror database for the principal/primary database. For more information, see Preparing a Mirror Database for Mirroring.
Set up database mirroring. For more information, see How to: Configure a Database Mirroring Session (SQL Server Management Studio) or Setting Up Database Mirroring.
Restore backups of the principal/primary database to other server instances to be later used as log shipping secondary databases for the primary database. For more information, see Configuring Log Shipping.
Set up log shipping on the principal database as the primary database for one or more secondary databases.
You should set up a single share as the backup directory (a backup share). This ensures that after role switching between the principal and mirror servers, backup jobs continue to write to the same directory as before. A best practice is to ensure that this share is located on a different physical server from the servers hosting the databases involved in mirroring and log shipping.
For more information, see How to: Enable Log Shipping (SQL Server Management Studio).
Set up log shipping on the mirror as the inactive primary database.
You must use the same backup share that is being used by the principal/primary and the secondary servers. Do not perform any setup from the secondary(s) for the mirror/primary. The primary server specified when configuring the secondary server is not used for the mechanics of shipping the logs to the secondary. Log shipping just copies files and a secondary server does not connect to the primary server instance defined on the secondary.
The Transaction Log Shipping interface in SQL Server Management Studio supports only one primary database per log shipping configuration. Therefore, you must use stored procedures to set up the mirror/primary. For more information, see How to: Enable
Database Mirroring and Log Shipping
A given database can be mirrored or log shipped; it can also be simultaneously mirrored and log shipped. To choose what approach to use, consider the following:
How many destination servers do you require?If you require only a single destination database, database mirroring is the recommended solution. If you require more than one destination database, you need to use log shipping, either alone or with database mirroring. Combining these approaches gives you the benefits of database mirroring along with the support for multiple destinations provided by log shipping.
If you need to delay restoring log on the destination database (typically, to protect against logical errors), use log shipping, alone or with database mirroring.
This topic discusses considerations for combining log shipping and database mirroring.
SQL 2005 Database Mirroring and Log Shipping
Setting Up Mirroring and Log Shipping Together
Setting Up Mirroring and Log Shipping Together
To set up database mirroring and log shipping together, the following steps are required:
Restore backups of the principal/primary database with NORECOVERY onto another server instance to be later used as database mirroring mirror database for the principal/primary database. For more information, see Preparing a Mirror Database for Mirroring.
Set up database mirroring. For more information, see How to: Configure a Database Mirroring Session (SQL Server Management Studio) or Setting Up Database Mirroring.
Restore backups of the principal/primary database to other server instances to be later used as log shipping secondary databases for the primary database. For more information, see Configuring Log Shipping.
Set up log shipping on the principal database as the primary database for one or more secondary databases.
You should set up a single share as the backup directory (a backup share). This ensures that after role switching between the principal and mirror servers, backup jobs continue to write to the same directory as before. A best practice is to ensure that this share is located on a different physical server from the servers hosting the databases involved in mirroring and log shipping.
For more information, see How to: Enable Log Shipping (SQL Server Management Studio).
Set up log shipping on the mirror as the inactive primary database.
You must use the same backup share that is being used by the principal/primary and the secondary servers. Do not perform any setup from the secondary(s) for the mirror/primary. The primary server specified when configuring the secondary server is not used for the mechanics of shipping the logs to the secondary. Log shipping just copies files and a secondary server does not connect to the primary server instance defined on the secondary.
The Transaction Log Shipping interface in SQL Server Management Studio supports only one primary database per log shipping configuration. Therefore, you must use stored procedures to set up the mirror/primary. For more information, see How to: Enable
Subscribe to:
Posts (Atom)