Archive for April, 2014

ITSM Integration powered by easyCloud

Kategorien: Knowledge Base
Kommentare deaktiviert für ITSM Integration powered by easyCloud

Introduction

What has been standard within the classical manufacturing and other producing industries for several decades becomes more important to IT organizations nowadays: tailoring standard processes from best practices and implementing these processes with the help of integrated software.

Many IT organization – independently if internal or external – currently concentrate their strategical activities on adopting and implementing IT processes like those found in the ITIL framework. However, not only the processes itself are introduced, further more tools and software suites are being implemented to support these processes.

These described circumstances lead to several challenges, which can be divided into organizational and technical challenges. On the one hand, changing the processes – and therefore the way people used to act for a certain time – is not always easy. On the other hand, as soon as these processes are agreed upon, the chosen tools or tool suites need to communicate and integrate into the existing landscape. Commonly, this results in integrating a multitude of different platforms, applications and technology components into one leading ITSM tool (suite).



SAP applications – like SAP ERP, SAP BW, SAP CRM etc. – often act as important part of the offered service portfolio, supporting the established business processes and business services. The integration of ITSM processes and SAP ALM processes is therefore an important topic to be discussed. In addition, the concrete integration of ITSM software with SAP software needs to be discussed.

This blog post is not about how to choose ITSM software or what software should be used. Further on, this blog will not give an overview of what ITIL or ITSM and how to implement ITSM processes within organizations. This blog is rather about the integration of SAP solutions into an existing or newly implemented Non-SAP-ITSM software (e.g. like Microsoft System Center Service Manager, ServiceNow, BMC, etc.). It tries to answer questions about what might be suitable for integration and how to integrate it.

Possible Scenarios

First of all, let us have a closer look on possible scenarios, where an integration makes sense. During some customer projects, four main areas emerge as the key points of interest and integration: Change Management, Incident Management, Event/Capacity Management and CMDB design. Within the next few chapters, these scenarios will be detailed and evaluated. Possible solutions will be recommended in the trailing chapters of this blog post.

Change Management

SAP has its own processes established for a – more or less – technical change management: SAP Transport Management System. The STMS defines transportation routes between SAP systems and „packages“ every modified or newly created object into a transport request, which can be transported within the landscape. Further on, SAP delivers Change and Request Management (ChaRM) as part of the SAP Solution Manager. ChaRM implements change request management processes with a tight integration into the underlying SAP technology (e.g. STMS).

So, if SAP offers its own its own implementation of Change and Request Management, why should one think about integration? Wouldn’t it be easier to use SAP’s ChaRM for SAP changes? Indeed – but then there would be at least two entry points: one request entry for SAP changes, one entry point for Non-SAP changes. Moreover, what needs to be done, if the change is for SAP and Non-SAP?


Therefore, the first reason to integrate SAP and Non-SAP ITSM is a central entry point for Change Management. This way, key users and change managers can create and track Change Requests during their way towards becoming a change and being implemented. In addition, this should be possible on a higher level, independent from the application and infrastructure underneath.

The second reason, from the perspective of the application owner, is traceability and auditability of changes made to the offered IT services, especially changes made to critical SAP applications. Even if the application owners use their own software for technical or non-technical change management, redundant maintenance of information should be avoided – as far as possible. An integration between a central ITSM tool and the SAP Change Management would solve this issue by either integrating the process layer from the ITSM tool with SAP ChaRM or directly with the SAP TMS.



Event Management

The next possible integration scenario is based on the requirements for a central event management. Common organizations have an SAP Basis team, which monitors their SAP systems on a daily basis. By introducing a central management and monitoring system of IT Services and IT Service Management, monitoring of available IT Services and the underlying applications and infrastructure should be done within these central applications. Critical events should be forwarded to the central software for monitoring and event management. For further analysis, it is – as with any other application – required to work with the SAP system itself. Nevertheless, alerting can be done centrally, which also makes it easier to aggregate and report these information. Furthermore, these information can be used as foundation for SLA reporting.


CMDB

Another example for integrating SAP and a third party ITSM tool is the enrichment of the central CMDB with SAP Applications, SAP Application Components and versions. This way one has a CMDB with all these SAP related information automatically maintained within the central CMDB, which makes the process integration, e.g. within Incident Management, much easier and much more comfortable.



Incident Management

The integration between the Incident Management process and SAP is also a common requirement. Adding additional information for incident tickets is always helpful for solving the incident. Either through adding information directly while creating the incident, or by enriching the incident ticket while working on it, the incident resolution can be accelerated.

As example, an incident ticket could be enriched by general information like the SAP System, the installed application components and versions and further on, additional information about the user could be added. This may include the locked-status of the user or recent authorization issues, which are helpful for processing and solving the incident, but also for using the incident database as Knowledgebase.


SQL Server AlwaysOn – kein automatischer Failover bei Verlust von Datenbank-Files

Kategorien: Allgemein, Knowledge Base
Kommentare deaktiviert für SQL Server AlwaysOn – kein automatischer Failover bei Verlust von Datenbank-Files

SQL Server AlwaysOn – kein automatischer Failover bei Verlust von Datenbank-Files

Seit SQL Server Release 2012 stellt Microsoft eine neue Hochverfügbarkeitstechnologie namens „AlwaysOn“ zur Verfügung, die in die Datenbanksoftware integriert ist und das bestehende Angebot an Hochverfügbarkeitslösungen ergänzt. In Zukunft soll AlwaysOn den Datenbankspiegel sogar komplett ablösen (siehe Hochverfügbarkeitslösungen – MS Technet)

In diesem Beitrag möchten wir die AlwaysOn-Technologie näher erläutern, uns aber auch einer Problemkonstellation widmen, die mit deren Einsatz auftreten kann.

Was ist AlwaysOn?

Die SQL Server AlwaysOn (AO) Technologie ist bereits umfassend online beschrieben und dokumentiert. Besonders hervorzuheben sind die FaQ auf den Technet-Seiten von Microsoft Microsoft Technet – AlwaysOn FAQ sowie dieser sehr anschauliche Blogbeitrag von Jürgen Thomas: SQL Server 2012 AlwaysOn – What is it?

Kurz gesagt:

AlwaysOn ist neben Database Mirroring (DBM) und Clustering des SQL Servers eine alternative Hochverfügbarkeitslösung für SQL Server Datenbanken, deren Ziel es ist, alle Vorteile aus der Kombination der beiden genannten HA-Lösungen zu vereinbaren und gleichzeitig deren Nachteile auszumerzen.

Die Komplexität einer geclusterten SQL Server Instanz wird bei AO durch lokal installierte SQL Server Instanzen mit lokal angebundenem Storage vermieden. Die Datenbank ist wie bei DBM auf jedem Server lokal vorhanden.

Im Gegensatz zu DBM lässt sich eine über AO abgesicherte Datenbank über einen einheitlichen DNS-Namen / IP-Adresse ansprechen. Die Applikation, die die Datenbank nutzt, hat somit Transparenz über einen eventuell erfolgenden Failover und muss nicht zur Laufzeit einen anderen Datenbankserver ansprechen.

Zahlreiche Geschäftsprozesse werden in der heutigen Zeit in IT-Systemen abgebildet und deren Ausführung erfordert die Verfügbarkeit und korrekte Funktionsweise der zugrundeliegenden Systeme. Besonders bei Systemen, die von geschäftskritischen Prozessen genutzt werden, kann Nichtverfügbarkeit zu hohen finanziellen Verlusten führen. Nutzer bzw. Administratoren müssen sich daher darauf verlassen können, dass die durch die Hochverfügbarkeitstechnologie abgesicherten Datenbanken auch im Fehlerfall (Hardwareausfälle und dergleichen) jederzeit erreichbar sind. Doch funktioniert AlwaysOn in jeder denkbaren Fehlersituation zuverlässig und wie zu erwarten?

Wie reagiert SQL-Server bzw. die durch AlwaysOn gesicherte Datenbank auf den Verlust der primären Anbindung (Ausfall der Festplatten oder SSDs)?

Um diese Frage zu klären haben wir folgende Testumgebung aufgebaut:

  • Betriebssystem-Plattform Windows Server 2012 R2
  • SQL Server 2012 SP1 CU2 (dabei ist der genaue Patchlevel unerheblich, das Folgende gilt für alle SQL Server 2012 ab RTM)
  • Anbindung der LUNs für die durch AO abgesicherte Test-DB mit iSCSI (internet Small Computer System Interface)
  • Einrichtung von Windows Server Failover Clustering
  • Bereitstellung einer Test-DB auf den iSCSI-LUNs
  • Einrichtung einer SQL Server AO Verfügbarkeitsgruppe

     

Abbildung 1: AlwaysOn Testaufbau

Wie in Abbildung 2 ersichtlich ist, befinden sich die Datenbanken momentan auf den beiden AlwaysOn Testservern in einem synchronisierten Zustand.

Abbildung 2: Synchrone Datenbanken im AO

 

Nun versuchen wir, den Ausfall der primären Disk-Anbindung zu simulieren, indem wir die Festplatte, auf der die Datenfiles der primären Datenbank liegen, im Disk Manager offline setzen.

Zu erwarten wäre, dass SQL Server 2012 den Ausfall bemerkt und entsprechend mit einem Failover darauf reagiert.

Abbildung 3: Simulierter Festplattenausfall

Wechselt man nun zum AO-Dashboard und refresht den AlwaysOn-Status, sieht man jedoch, dass dieses trotz „Ausfall“ der Festplatte weiterhin davon ausgeht, dass die Datenbanken synchron sind. Auch das SQL-Server Errorlog der primären Datenbankinstanz verzeichnet selbst Sekunden nach dem „Ausfall“ der Festplatte, auf der eigentlich die Datenfiles der Datenbank liegen, keine Probleme.

Kritischer Status:

Beim Zugriff auf ein beliebiges Datenbankobjekt in dieser Datenbank (hier mittels SQL Server Management Studio) erscheint dann allerdings folgende Fehlermeldung:

Abbildung 4: Hinweis: Zugriff auf DB nicht mehr möglich, DB-Check wird empfohlen

 

Als Administrator würde man basierend auf dieser Fehlermeldung vermuten, dass die Festplatte, auf der die Datenfiles der primären Datenbank liegen, defekt ist und als Korrekturmaßnahme einen Failover über AlwaysOn auslösen, um die Datenbank auf der vermeintlich synchronen sekundären Seite zu öffnen. Doch SQL Server kann in diesem Zustand mit gewisser Wahrscheinlichkeit nicht mehr auf die bis dahin synchrone zweite Datenbank failovern! Im SQL Server Errorlog der sekundären Datenbankinstanz taucht folgende Fehlermeldung auf:

 

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.

 

 

Fazit:

AlwaysOn verhält sich in einem solchen Fall auf den ersten Blick hin unerwartet:

  • Es wird kein Failover ausgelöst, wenn sich der Status einer der durch AO abgesicherten Datenbank ändert. Warum ist das so?
    Weil AlwaysOn keine Verfügbarkeitsprüfung auf Datenbankebene ausführt. Im Gegensatz zum Datenbankspiegel bietet AO wie SQL-Clustering die Möglichkeit, mehrere Datenbanken logisch zu gruppieren und bei Bedarf gemeinsam zu failovern. Dies ist für die Betrachtung des Verhaltens von entscheidender Bedeutung. Die Prüfung und Bewertung der Verfügbarkeit findet bei AlwaysOn nicht auf Ebene der einzelnen Datenbank statt, sondern auf der Ebene der SQL Server Instanz und der AO Availability Group. Dies ist ein entscheidender Unterschied zum Verhalten von Database Mirroring, denn Mirroring prüft die Verfügbarkeit der einzelnen abgesicherten Datenbanken und löst auch dann einen Failover aus, wenn die Verfügbarkeit der Datenbank auf dem primären Server beeinträchtigt ist.

    Dies ist im SAP Hinweis 1772688 (Login nötig) nachzulesen:
    „Letzteres hat auch eine Änderung in der Granularität von Health-Checks oder Indikationen erzwungen, die einen Failover auslösen könnten. Das Schließen einer Datenbank infolge von z.B. einem Datenträgerausfall löst in DBM einen Failover aus (wenn ein automatischer Failover konfiguriert ist). Wohingegen die Health-Checks in AlwaysOn hauptsächlich in der Verfügbarkeitsgruppe stattfinden und die SQL-Server-Instanz die Verfügbarkeitsgruppe als primär ausführt. Bei der Integritätsermittlung wird aber nicht der Zustand der einzelnen Datenbanken geprüft, die sich in der Verfügbarkeitsgruppe befinden. Folglich kann eine Datenbank innerhalb einer Verfügbarkeitsgruppe geschlossen werden, z.B. ausgelöst durch einen Datenträgerausfall, ohne dass die Verfügbarkeitsgruppe in einen problematischen Zustand gerät oder einen Failover auslöst (sofern der automatische Failover konfiguriert ist). Dies stellt im Vergleich zu DBM eine drastische Änderung im Verhalten und im Abdeckungsbereich dar. Insbesondere im Fall von Datenträgerausfällen, die durch sekundäre Auswirkung das Schließen von betroffenen SQL-Datenbanken verursachen, löst DBM einen Failover aus, wohingegen AlwaysOn in der Standardeinstellung keinen Failover auslöst.“

  • Die Datenbanken befinden sich nach einem Storage-Defekt auf Primärseite in einem vermeintlich asynchronem Zustand, sodass die in Wirklichkeit synchrone sekundäre Datenbank so geöffnet werden muss als wäre sie eine asynchron gehaltene Datenbank (‚with allow_data_loss‘)
    Dabei ist der Zustand der sekundären AO-Datenbank identisch zum Status der sekundären DBM-Datenbank bei einem vergleichbaren Datenbankfehler. Die Datenbanken sind mit beiden Technologien gleichartig synchron bzw. asynchron, AlwaysOn beurteilt hier jedoch konservativer, als DBM und ändert den Status der Sekundär-Datenbanken auf Out-of-Sync (wie es bei einem asynchron betriebenen Datenbankspiegel bzw. asynchronem AO generell und dauerhaft der Fall ist)

 

Das Verhalten beim Verlust von Log- oder Datenfiles ist bei AlwaysOn und Database Mirroring so lange identisch, bis die geschützte Datenbank geschlossen wird. Hier liegt der Unterschied zwischen den beiden HA-Lösungen in der Automatisierung. AlwaysOn bietet nur so lange Hochverfügbarkeit, wie die Integrität der Datenbankdateien der aktuellen Primärdatenbank gegeben ist. Geht die Primäre Datenbank z.B. durch Storage/SSD-Ausfall oder iSCSI-Verbindungsverlust verloren, wird die Datenbank je nach Laufzeitzustand als „out of sync“ markiert und erfordert ein manuelles Eingreifen. Database Mirroring dagegen schwenkt je nach Konfiguration automatisch bei Verlust von Daten- oder Logfiles auf den Spiegel.

Wenn mit einem manuellen Eingreifen und Starten des Spiegels die SLAs weiterhin erfüllt werden, spricht aus Sicht der Datenkonsistenz nichts gegen die Verwendung der Hochverfügbarkeitslösung SQL Server AlwaysOn.