All posts in Allgemein @en

cmWatcher User Manual

Kategorien: Allgemein @en, cmWatcher @en, knowledge base @en
Comments Off on cmWatcher User Manual

Intro

You want to install and configure cmWatcher. Therefore you want to have the latest User Manual available.

Solution

This note contains the latest User Manual. Please use the following link to download ist:

“connmove_cmWatcher_UserManual_EN”.


How to install cmWatcher in a cluster

Kategorien: Allgemein @en, cmWatcher @en, knowledge base @en
Comments Off on How to install cmWatcher in a cluster

Intro

Your monitoring concept requests a high available monitoring solution for Microsoft System Center Operation Manager (SCOM) and SAP components. Therefore also connmove cmWatcher shoud be high avilable.

connmove cmWatcher supports a configuration in a Microsoft Failover Cluster environment. With this configuration, cmWatcher is protected against single Hardware outages and single Operating systems outages.

This article describes how to install and configure cmWatcher in a Microsoft Failover Cluster. It describes how to configure a generic service within the microsoft failover cluster role.

Solution

Architecture:

cmWatcher Failover Cluster configuration is supported in a two node configuration. Alike other cluster configuration, cmWatcher with its specific functionality has special demands on the cluster configuration:

IP Adresss:
The cluster Service does not need a specific IP adress, because cmWatcher connects to the systems and database. No connections goes to the cmWatcher installation directly

Cluster shared Storage
cmWatcher is normaly installed in c:program files. Of couse you can install it directly on a cluster shared disk. But while cmWatcher stores configuration and status items in the database, there is not really a need to do so. It’s suitable to install cmWatcher on both Cluster nodes on local disks.
Disadvantage off this local configuration: Patches of cmWatcher must be done on both nodes.

Prequesites:

cmWatcher runs in a Microsoft Failover Cluster. connmove recomment the cluster configuration itself along to current Microsoft Failover Cluster configuration guidelines. connmove support this kind of configuration in Microsoft Failover Cluster with Windows Server version 2008 R2 and above, x64 bit only.

 

Installation of cmWatcher:

Install cmWatcher (for additional information, see the cmWatcher manual)  on the respective nodes of the cluster. Note: The cmWorker service has to be stopped. After the installation of the cmWatcher instances the database connection of one cmWatcher instance has to be configured. Then change to the directory of the cmWatcher “C:Program FilesConnmove GmbHcmWatcher” and copy the “cmWatcherSettings” file to the other nodes.

Creating cluster service:

Open the Failover Cluster Manager and click on “Create Empty Role”.

FailoverClusterManager

The new role will appear in the Roles list. Double clicking the role opens the properties window. Specify the name for the role and select the cluster nodes on which you have installed cmWatcher. Apply changes and close the window.

FailoverClusterManager_RoleProperties

Right click on the role and select “Add Resource/Generic Service”.

FailoverClusterManager_RoleAddRessource

 

The “New Resource Wizard” window opens. Choose the cmWorker service from the list and click next until the wizard finishes.

FailoverClusterManager_RoleSelectService

FailoverClusterManager_RolePropertiesConfirmation

FailoverClusterManager_RolePropertiesSummary

Right click on the role entry and choose “Start Role”.

FailoverClusterManager_StartRole

The cmWorker service will now start on one of the specified cluster nodes.

FailoverClusterManager_RunningRole

You now succesfully completed the cmWatcher cluster installation.

 


SQL Server AlwaysOn – no automatic failover when database files are lost

Kategorien: Allgemein @en, knowledge base @en, News @en
Comments Off on SQL Server AlwaysOn – no automatic failover when database files are lost

With SQL Server Release 2012, Microsoft has introduced a new high-availability technology named “AlwaysOn”. It comes integrated with the database software and extends Microsoft’s high-availability portfolio. AlwaysOn is intended to eventually replace Database Mirroring entirely (refer to High Availability Solutions – MS TechNet).

In this post, we would like to familiarize you with the AlwaysOn technology, but also investigate a constellation of problems that can arise from its use.

What is AlwaysOn?

The SQL Server AlwaysOn (AO) technology has been extensively researched and documented online. We would like to point you to the FAQ on Microsoft’s TechNet website (Microsoft TechNet – AlwaysOn FAQ) and this insightful blog post by Juergen Thomas: SQL Server 2012 AlwaysOn – What is it?.

To put it simply:

AlwaysOn is an alternative high-availability solution for SQL Server databases that is available alongside Database Mirroring (DBM) and SQL Server Clustering. Its objective is to combine the advantages of these two HA solutions, while eliminating all of their disadvantages.

AO mitigates the complexity of a clustered SQL Server instance by means of locally installed SQL Server instances with locally attached storage. As with DBM, the database exists locally on each server.

Other than with DBM, however, a database secured with AO can be addressed using a unique DNS name / IP address. The application that uses the database is not aware of a potential failover and does not have to address another database server at runtime.

Today, a wide variety of business processes is mapped in IT systems and their execution depends on the availability and proper functioning of the systems they are based on. Particularly when it comes to systems that drive business-critical processes, downtime can result in significant financial losses. Users and administrators need to know that the databases that are protected by high-availability technologies will be available at any time even in case of error (hardware failures and the like). But does AlwaysOn function reliably and as expected for every conceivable error?

How does SQL Server / the database protected by AlwaysOn respond if the primary connection is lost (failure of the hard disks or SSDs)?

To answer this question, we set up the following test environment:

  • Operating system platform Windows Server 2012 R2
  • SQL Server 2012 SP1 CU2 (the exact patch level is irrelevant, the following applies to all SQL Server 2012 versions starting with RTM)
  • iSCSI-connected (internet Small Computer System Interface) LUNs for the test database protected by AO
  • Setup of Windows Server Failover Clustering
  • Provision of a test database on the iSCSI LUNs
  • Setup of an SQL Server AO Availability Group

     

Figure 1: AlwaysOn test setup

 

As illustrated in figure 2, the databases on both AlwaysOn test servers are currently synchronized.

Figure 2: Synchronous databases in AO

 

Now we will try to simulate the failure of the primary disk connection by setting the hard disk on which the data files of the primary database reside to offline in the Disk Manager.

One would expect SQL Server 2012 to detect the failure and respond accordingly by triggering a failover.

Figure 3: Simulated hard disk failure

Upon switching to the AO dashboard and refreshing the AlwaysOn status, one will quickly see that despite the “failure” of the hard disk it still considers the databases to be synchronous. Even the SQL Server error log of the primary database instance does not indicate any problems seconds after the “failure” of the hard disk on which the data files of the database reside.

Critical status:

But as soon as one tries to access any database object in this database (in this case using SQL Server Management Studio), the following error message appears:

Figure 4: Message: DB cannot be accessed anymore, DB check is recommended

 

Based on this error message, an administrator would assume that the hard disk on which the data files of the primary database reside is defective and counteract by triggering a failover with AlwaysOn in order to open the database on the secondary side, which is assumed to be synchronous. It is fairly likely, however, that in this state SQL Server will no longer be able to fail over to the up-to-then synchronous second database! The SQL Server error log of the secondary database instance displays the following error message:

 

AlwaysOn: The local replica of availability group ‘AOGroupSLM’ is preparing to transition to the primary role in response to a request from the Windows Server Failover Clustering (WSFC) cluster. This is an informational message only. No user action is required.

The availability replica for availability group ‘AOGroupSLM’ on this instance of SQL Server cannot become the primary replica. One or more databases are not synchronized or have not joined the availability group, or the WSFC cluster was started in Force Quorum mode. If the cluster was started in Force Quorum mode or the availability replica uses the asynchronous-commit mode, consider performing a forced manual failover (with possible data loss). Otherwise, once all local secondary databases are joined and synchronized, you can perform a planned manual failover to this secondary replica (without data loss). For more information, see SQL Server Books Online.

 

 

Conclusion:

The behavior shown by AlwaysOn in such cases is, at first, unexpected:

  • No failover is triggered if the status of a database protected by AO changes. Why is this the case?
    Because AlwaysOn does not perform an availability check on the database level. Other than Database Mirroring, AO just like SQL clustering allows for the logical grouping of multiple databases that can be failed over together if necessary. This must be considered when looking at its behavior. With AlwaysOn, availability is not checked and assessed on the level of individual database, but rather on the level of the SQL Server instance and the AO Availability Group. This is what sets it apart from the Database Mirroring behavior, which checks the availability of the individually protected databases and triggers a failover as soon as the availability of the database on the primary server is affected.

    The following information can be found in SAP Note 1772688 (login required):
    “The latter point also forced a change in the granularity of health checks or indications which would trigger a failover. In DBM the close of a database as result of e.g. a disk failure will trigger a failover (if automatic failover is configured). Whereas in AlwaysOn the health checks are mainly around the Availability Group and the SQL Server instance running the Availability Group as primary. But health detection is not checking the health of the individual databases which are contained in an Availability Group. As a result a database within an Availability
    Group can be closed, triggered e.g. by a disk failure without the AG moving into an unhealthy state or triggering a failover (if automatic failover got configured). This is a drastic change in behavior and coverage area compared to DBM. Especially in the case of disk failures which as a secondary effect cause affected SQL Server databases to close, DBM triggered a failover, whereas AlwaysOn in its default settings won’t trigger a failover.”

  • Following a storage defect on the primary side, the databases are assumed to be out of sync, making it necessary to open the secondary database, which is actually synchronous, as if it were an asynchronously replicated database (‚with allow_data_loss’).
    The actual status of the secondary AO database, however, is identical to that of the secondary DBM database for a similar database error. The databases are equally synchronous or asynchronous with both technologies, but AlwaysOn is more conservative in its assessment than DBM and changes the status of the secondary database to out-of-sync (which is always is case an asynchronously mirrored databases or asynchronous AO).

 

The behavior when log or data files are lost is the same for both AlwaysOn and Database Mirroring until the protected database is closed. Here, the difference between the two HA solutions lies in their level of automation. AlwaysOn will only provide high availability for as long as the integrity of the database files of the current primary database is maintained. In cases, however, where the primary database is lost due to problems such as storage/SSD failure or iSCSI connection loss, the database, depending on its runtime status, is marked as “out of sync” and requires manual intervention. Database Mirroring on the other hand will, depending on its configuration, automatically fail over to the mirror when data or log files are lost.

From a data consistency perspective, there is no reason not to use the SQL Server AlwaysOn high availability solution, if SLAs are continued to be met after manual intervention and starting the mirror.


EasyCloud Cmdlets for managing SAP Users

Kategorien: Allgemein @en
Comments Off on EasyCloud Cmdlets for managing SAP Users

There are new cmdlets to manage Sap user data:

  • Get-CmSapUserDetails
  • Set-CmSapUserDetails
  • Get-CmSapUserAuthorizationData

Get-CmSapUserDetails

Returns detail informations of a user.

Image 1 shows the different return data:

EasyCloud_Sap_User_1

Image 2 shows how to read an information like the E-Mail:

EasyCloud_Sap_User_2

 

Set-CmSapUserDetails

With this Cmdlet you can change a lot of data of an Sap User:

EasyCloud_Sap_User_3

Here are a few informations which can be changed by using the cmdlet:

  • Data of Person (Name, etc.)
  • Contact Informations (Address, E-Mail, etc.)
  • SNC
  • User Password
  • User Type
  • User Group
  • Validity Period
  • etc.

 

 Get-CmSapUserAuthorizationData

Checks if a user has authorization issues. The function returns the output of the TC SU53.

EasyCloud_Sap_User_4