Sunday, December 16, 2007
Saturday, December 15, 2007
ESXGuide - esxcfg VMware console tool
ESXGuide - esxcfg VMware console tool
esxcfg tool Management in the console
esxcfg-rescan
esxcfg-rescan vmhba1
esxcfg-rescan vmhba2
Rescan vmhbas
esxcfg-mpath -l
VMware ESX Server multipathing information
Disk vmhba1:3:6 /dev/sdu (225280MB) has 2 paths and policy of Most Recently Used
FC 2:1.0 210000e08b0246af<->201400a0b81167e2 vmhba1:3:6 On active preferred
FC 4:1.0 210000e08b02e4a0<->201500a0b81167e2 vmhba2:3:6 Standby
Multipathing of HBAS listing and configure
esxcfg-vmhbadevs -m
See the relationship between vmhba and devnames. This produces an output like so:
vmhba1:3:6:1 /dev/sdu1 44ebf538-51cc7998-2525-00145e1b556a
vdf
/vmfs/volumes/44ebf538-51cc7998-2525-00145e1b556a
230424576 44748800 185675776 19% /vmfs/volumes/CoreDomain
Relationship between Vmhbas and devname
ls /vmfs/devices/disks/
list all your disks/luns like so:vmhba0:0:0:0
vmhba0:1:0:0
vmhba1:2:0:0
vmhba1:3:0:0
vmhba1:4:0:0
vmhba1:5:0:0
vmhba1:6:0:0
vml.02000000003343453035595041202020203731303638315430535831373334
vml.0200000000334345303634504b202020203731303545464853535831373334
vml.0200000000334345304150415420202020373131384b51305a535831373334
vml.0200000000334345304244584e202020203731313835485231535831373334
vml.0200000000334345304446543230303030373132314e4c5a57535431373334
vml.02000000005546413350323330375352544d414e333336
vml.02000000005546413350323330375442444d414e333336
You can then use fdisk to work out if the disks are blank of partitioned with:
fdisk /vmfs/devices/disks/vmhba1:5:0:0
Not an esxcfg command but very useful
Identify the LUN Disk and Partition
vmhbax:y:z:v
x=Hostbusadapter (0=mostly internal SCSI Adapter, 1=mostliy fibrechannel 1...x)
y=LUN
z=Disk
v=Partition
esxcfg-firewall
esxcfg-firewall --openPort
esxcfg-firewall --closePort
port: Apllication Port
Protocol:tcp or udp
Direction: in or out
name: Descriptive name of rule
esxcfg-firewall -q to query settings
Example:
esxcfg-firewall --openPort 14247,tcp,out,IBMDirector
You cannot configure unsupported services through the VI Client.
Firewall settings
esxcfg-vmhbadevs
vmhba0:0:0 /dev/sda
vmhba0:1:0 /dev/sdb
vmhba0:2:0 /dev/sdc
Map of VMkernel storage devices to service console devices
VMkernel storage devices to service console devices
esxcfg-vswitch
esxcfg-vswif -i 192.168.1.55 -n 255.255.255.0 vswf0
Creates and updates virtual machine network settings
Change IP Address and Subnetmask
esxcfg tool Management in the console
esxcfg-rescan
esxcfg-rescan vmhba1
esxcfg-rescan vmhba2
Rescan vmhbas
esxcfg-mpath -l
VMware ESX Server multipathing information
Disk vmhba1:3:6 /dev/sdu (225280MB) has 2 paths and policy of Most Recently Used
FC 2:1.0 210000e08b0246af<->201400a0b81167e2 vmhba1:3:6 On active preferred
FC 4:1.0 210000e08b02e4a0<->201500a0b81167e2 vmhba2:3:6 Standby
Multipathing of HBAS listing and configure
esxcfg-vmhbadevs -m
See the relationship between vmhba and devnames. This produces an output like so:
vmhba1:3:6:1 /dev/sdu1 44ebf538-51cc7998-2525-00145e1b556a
vdf
/vmfs/volumes/44ebf538-51cc7998-2525-00145e1b556a
230424576 44748800 185675776 19% /vmfs/volumes/CoreDomain
Relationship between Vmhbas and devname
ls /vmfs/devices/disks/
list all your disks/luns like so:vmhba0:0:0:0
vmhba0:1:0:0
vmhba1:2:0:0
vmhba1:3:0:0
vmhba1:4:0:0
vmhba1:5:0:0
vmhba1:6:0:0
vml.02000000003343453035595041202020203731303638315430535831373334
vml.0200000000334345303634504b202020203731303545464853535831373334
vml.0200000000334345304150415420202020373131384b51305a535831373334
vml.0200000000334345304244584e202020203731313835485231535831373334
vml.0200000000334345304446543230303030373132314e4c5a57535431373334
vml.02000000005546413350323330375352544d414e333336
vml.02000000005546413350323330375442444d414e333336
You can then use fdisk to work out if the disks are blank of partitioned with:
fdisk /vmfs/devices/disks/vmhba1:5:0:0
Not an esxcfg command but very useful
Identify the LUN Disk and Partition
vmhbax:y:z:v
x=Hostbusadapter (0=mostly internal SCSI Adapter, 1=mostliy fibrechannel 1...x)
y=LUN
z=Disk
v=Partition
esxcfg-firewall
esxcfg-firewall --openPort
esxcfg-firewall --closePort
port: Apllication Port
Protocol:tcp or udp
Direction: in or out
name: Descriptive name of rule
esxcfg-firewall -q to query settings
Example:
esxcfg-firewall --openPort 14247,tcp,out,IBMDirector
You cannot configure unsupported services through the VI Client.
Firewall settings
esxcfg-vmhbadevs
vmhba0:0:0 /dev/sda
vmhba0:1:0 /dev/sdb
vmhba0:2:0 /dev/sdc
Map of VMkernel storage devices to service console devices
VMkernel storage devices to service console devices
esxcfg-vswitch
esxcfg-vswif -i 192.168.1.55 -n 255.255.255.0 vswf0
Creates and updates virtual machine network settings
Change IP Address and Subnetmask
Round-Robin Load Balancing - VMware ESX Server 3.5, VMware ESX Server 3i version 3.5, VMware VirtualCenter 2.5
http://www.vmware.com/pdf/vi3_35_25_roundrobin.pdf
The following options are supported and discussed in more detail in Table 1.
esxcfg-mpath --lun [--policy [mru|rr|fixed|custom]]
[--custom-hba-policy|-H [mru|preferred|any|minq]] |
[--custom-target-policy|-T [mru|preferred|any]] |
[--custom-max-commands|-C] |
[--custom-max-blocks|-B]
Notes
If you set the custom-max-blocks and custom-max-commands, options, the system attempts to switch paths
as soon as one of the limits is reached.
If you set the target or the HBA policy to preferred, the system chooses the target or the HBA of the preferred
path when possible. If a preferred policy is set on an active/passive SAN array, and the preferred target is not
on the active SP (Storage Processor), the system does not select the preferred target but a target on the active SP.
Path switching is not performed if an outstanding SCSI reservation is on the target, or if a path failover is
underway. Path switching is delayed until an I/O request is performed when no reservations or path failovers
are pending.
Table 1. Policy Options for esxcfg-mpath
Option Description
--policy
-p
[mru|rr|fixed|custom]
Set the policy for a given LUN to mru, rr, fixed, or custom. This option requires that
the --lun option is also passed to indicate the LUN to set the policy for.
Most recently used (mru) selects the path most recently used to send I/O to a device.
Round robin (rr) uses the mru target selection policy and the any HBA selection
policy to select paths.
Fixed (fixed) uses only the active path.
Custom (custom) sets the LUN to expect a custom policy.
NOTE After you’ve set the policy to custom for a LUN, you can specify one or more of
the other options. For any LUN, you set the policy to custom only once.
--custom-hba-policy
-H
Selection policy for the HBA. Use one of the following:
preferred — Use the HBA that’s part of the preferred path.
mru – Use the most recently used HBA.
minq – HBA that has the smallest number of outstanding I/O commands when the
ESX Server system does the path selection.
any – Use any available HBA.
--custom-target-policy
-T
Selection policy for the target. Use one of the following:
preferred – Use the target that is part of the preferred path.
mru – Use the most recently used target.
any – Use any available target.
--custom-max-commands
-C
Maximum number of I/O requests to be issued on a given path before the system tries
to select a different path. A setting of zero (0) disables switching based on commands.
Specify the number of commands as an integer. Default is 50.
--custom-max-blocks
-B
Maximum number of I/O blocks to be issued on a given path before the system tries to
select a different path. A setting of zero (0) disables switching based on blocks.
Specify the number of blocks as an integer. Default is 2048.
The following options are supported and discussed in more detail in Table 1.
esxcfg-mpath --lun
[--custom-hba-policy|-H [mru|preferred|any|minq]] |
[--custom-target-policy|-T [mru|preferred|any]] |
[--custom-max-commands|-C
[--custom-max-blocks|-B
Notes
If you set the custom-max-blocks and custom-max-commands, options, the system attempts to switch paths
as soon as one of the limits is reached.
If you set the target or the HBA policy to preferred, the system chooses the target or the HBA of the preferred
path when possible. If a preferred policy is set on an active/passive SAN array, and the preferred target is not
on the active SP (Storage Processor), the system does not select the preferred target but a target on the active SP.
Path switching is not performed if an outstanding SCSI reservation is on the target, or if a path failover is
underway. Path switching is delayed until an I/O request is performed when no reservations or path failovers
are pending.
Table 1. Policy Options for esxcfg-mpath
Option Description
--policy
-p
[mru|rr|fixed|custom]
Set the policy for a given LUN to mru, rr, fixed, or custom. This option requires that
the --lun option is also passed to indicate the LUN to set the policy for.
Most recently used (mru) selects the path most recently used to send I/O to a device.
Round robin (rr) uses the mru target selection policy and the any HBA selection
policy to select paths.
Fixed (fixed) uses only the active path.
Custom (custom) sets the LUN to expect a custom policy.
NOTE After you’ve set the policy to custom for a LUN, you can specify one or more of
the other options. For any LUN, you set the policy to custom only once.
--custom-hba-policy
-H
Selection policy for the HBA. Use one of the following:
preferred — Use the HBA that’s part of the preferred path.
mru – Use the most recently used HBA.
minq – HBA that has the smallest number of outstanding I/O commands when the
ESX Server system does the path selection.
any – Use any available HBA.
--custom-target-policy
-T
Selection policy for the target. Use one of the following:
preferred – Use the target that is part of the preferred path.
mru – Use the most recently used target.
any – Use any available target.
--custom-max-commands
-C
Maximum number of I/O requests to be issued on a given path before the system tries
to select a different path. A setting of zero (0) disables switching based on commands.
Specify the number of commands as an integer. Default is 50.
--custom-max-blocks
-B
Maximum number of I/O blocks to be issued on a given path before the system tries to
select a different path. A setting of zero (0) disables switching based on blocks.
Specify the number of blocks as an integer. Default is 2048.
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)