MSSQL auf Linux – die Details
Als bekannt wurde, dass Microsoft MSSQL auf Linux portiert, dachte sich wohl so mancher Sysadmin, dass das in einer Katastrophe endet. Enterprise-Anbieter haben bisher nicht mit gelungenen Linux Ports geglänzt – Oracle DB auf einem Linux-Server zu installieren (und konfigurieren) gehört zu den mitunter schlimmsten Erfahrungen, die ein Admin sammeln kann. Bei Microsoft sieht das so aus:
$ curl https://packages.microsoft.com/config/rhel/7/mssql-server.repo | sudo tee /etc/yum.repos.d/mssql-server.repo
$ sudo yum update
$ sudo yum install mssql-server
Man mag sich verwundert die Augen reiben – Microsoft hat tatsächlich verstanden, wie man Software für Linux paketieren muss. \o/
Doch wie sieht MSSQL für Linux aus der Nähe aus? Engineers der Adfinis SyGroup wagten einen Blick hinter die Kulissen.
Unter der Haube
Eines der wichtigsten Credos beim Portieren von MSSQL auf Linux ist, dass sich das Laufzeitverhalten gegenüber Windows nicht verändert. Applikationen sollen nicht einmal merken, wenn im Backend ein Tux Einzug hält.
Hier stellt sich sofort die Frage, wie Microsoft ein solches Unterfangen löst, schliesslich gibt es immer Edge Cases, wenn man eine Lösung auf eine komplett andere Plattform portiert. Genau solche Edge Cases will man bei einer zentralen Enterprise-Anwendung ausschliesen, schliesslich könnten schon minimalste Regressions bei einer kritischen Lösung immense Schäden auslösen. Schaut man sich noch die vielen Abhängigkeiten an, welche MSSQL hat, stellt man fest, dass eine eigentliche Portierung inkl. aller Libs und Umgebungen wie CLR, eine Monster-Aufgabe darstellt, die sich vom Aufwand her nur schlecht rechtfertigen lässt. In solchen Situationen ist Erfindergeist gefragt und wir finden, dass Microsoft eine sehr kreative Lösung gewählt hat.
Eines sei schon im Voraus gesagt, Microsoft benutzt +/- die selben Executables und Libraries unter Linux wie unter Windows. Wie das ganze geht, erläutert die folgende Übersicht.
SQL OS
Bereits mit SQL Server 2005 hat Microsoft begonnen, Betriebssystem-abhängige Teile in einem eigenen Modul namens SQLOS zusammenzufassen. Das Ziel war damals jedoch noch nicht, andere Plattformen zu unterstützen, sondern tiefergreifende Monitoring- und Analysefunktionen bereitstellen zu können. Dies hatte jedoch den positiven Nebeneffekt, dass die meisten Zugriffe auf das Betriebssystem zentralisiert wurden. Dies wurde für die Portierung auf Linux später zu einem grossem Vorteil. Allerdings war diese Implementation natürlich noch nicht auf die Unterstützung verschiedener Betriebssysteme ausgelegt und viele Windows-Spezifika waren für die übergeordneten Schichten immer noch klar ersichtlich.
Mit diesem Layer könnten zwar die System-Aufrufe zentralisiert portiert werden, jedoch würden die weiteren Module und Bibliotheken, welche von SQL Server verwendet werden, davon immer noch nicht profitieren. Zum Glück hatte eine andere Abteilung innerhalb Microsoft mit dem Projekt Drawbridge begonnen, eine Abstraktion für Windows-Prozesse zu implementieren – ursprünglich, um die Virtualisierung von Windows-Systemen zu vereinfachen.
Drawbridge
Drawbridge ist ein Research Projekt von Microsoft, das schon 2011 das Licht der Welt erblickte. Im Grunde ging es bei Drawbridge darum, den Overhead bei der Virtualisierung von Windows Systemen zu reduzieren. Um dies zu erreichen, benötigte Microsoft knapp zusammengefasst folgende Bestandteile:
- Prozess-Isolation
- Layer, der das Windows ABI (Kernel/Syscalls) abbildet
- User Space Implementation der Windows APIs/Libs (win32 Subsystem)
- Treiber auf dem Gast-System um das Memory für die VM zu initialisieren
Diese Zutaten ergeben bereits ein relativ klares Bild, was bei Drawbridge passiert, wenn eine VM erstellt wird. Als erstes initiiert der Treiber auf dem Gast-System den Speicher für die virtuelle Maschine. In diesem Schritt wird ein Layer geladen, der das Windows ABI abdeckt – dies wird mit einem User Space NT Kernel bewerkstelligt. Zudem wird eine Library in den Speicher der VM geladen, welche die Windows APIs abbildet. Sowohl der User Mode Kernel wie auch die Library, welche die zahlreichen APIs abbildet, sind Bestandteil von LibOS. Sobald die VM mit LibOS initiiert ist, können darin Windows Binaries ausgeführt und Windows Libraries geladen werden ohne dass ein Syscall oder API-Aufruf die VM verlassen muss.
Drawbridge wurde gemäss unseren Informationen nie in ein Produkt integriert, zeigte aber auf, wie man “leichte Windows Virtualisierung” machen könnte.
LibOS
Wie bereits erwähnt, beinhaltet Drawbridge eine vollständige User Space-Implementation der Windows System Calls und der APIs die unter Windows benötigt werden. Das heisst, dass Drawbridge eine Art User Space Version des NT-Kernels implementierte (NTUM genannt – “user mode NT”) zudem gehört eine Library zu LibOS, welche die Windows APIs im User Space abbildet. Beide Elemente sind gegenüber den eigentlichen Implementationen in einer normalen Windows Umgebung massiv schlanker gehalten, ergeben aber eine Laufzeitumgebung, welche sich nichts anders verhält, als ein herkömmliches Windows.
SQL PAL
Drawbridge und SQLOS ermöglichen in Kombination, MSSQL Server unter Linux auszuführen, gehen aber in ihrer Implementation zum Teil viel zu weit und lösen teilweise die gleichen Probleme. Aus diesem Grund hat das Team bei Microsoft entschieden, die relevanten Teile zu extrahieren und aus Drawbridge, LibOS und dem Abstraktions-Layer SQLOS einen neuen Plattform-Abstraktionslayer (PAL) zu bauen. Dieser enthält nur die für SQL Server relevanten ABI und APIs und bietet alles, was nötig ist, um eine Laufzeitumgebung für MSSQL zu bieten. Die unterste Schicht besteht dabei aus einem Linux Binary (im User Space), welches den Rest der Umgebung initiiert.
Offene ToDos bezüglich SOS und LibOS
Der aktuelle Status ist, dass MSSQL auf Linux bereits problemlos funktioniert, jedoch ist das Team von Microsoft noch nicht fertig mit der Zusammenlegung von SOS und LibOS. So gibt es momentan zwei Versionen von SOS / LibOS innerhalb des SQL Servers für Linux, wobei die “obere” Version Calls an SQL PAL weiterleitet, welches wiederum die neuere Version von SOS verwendet, um via einer Host Bridge Anfragen an den Linux-Kernel zu senden. Microsoft arbeitet aktuell intensiv daran, diese Doppelspurigkeit zu eliminieren und die beiden Instanzen zu vereinheitlichen, damit am Schluss die gesamte Abstraktion in SQL PAL erledigt werden kann.
Die finale Architektur im Überblick
Wie erwähnt, haben Drawbridge und SQLOS einige Überschneidungen, welche Microsoft noch eliminiert. Generell bildet SQL PAL die Laufzeitumgebung für MSSQL und das RPM/DEB Paket bringt alle Executables sowie die nötigen zusätzlichen Windows Libraries mit um MSSQL, aufsetzend auf SQL PAL, ausführen zu können. Gemäss Microsoft werden rund 81MB unkomprimierte Windows Libraries mitgeliefert (das ist nur rund 1% einer kompletten Windows-Installation), das SQL PAL Binary ist rund 8MB gross.
Die Software landet übrigens in /opt und wird mit systemd verwaltet. Microsoft liefert dabei alles pfannenfertig und inklusive man pages aus.
Generell lässt sich der Prozess Ablauf, um MSSQL auf Linux zu starten, wie folgt beschreiben: die Host-Komponente (standard Linux Binary) startet als erstes SQL PAL und dieses initiiert wiederum den MSSQL Server in der “emulierten” Windows Umgebung.
Die finale Architektur sieht in etwa so aus:
Der geneigte Leser wird wohl bereits festgestellt haben, dass dieser Ansatz dem Windows Subsystem for Linux sehr ähnlich sieht.
Erste Erfahrungen
In Zusammenarbeit mit einem unserer Kunden arbeiten wir bereits an der ersten Migration einer MSSQL DB auf Linux.
Die ersten Erfahrungen sind sehr gut und zeigen, dass das Konzept auch in der Praxis funktioniert.
Für das Management der DB unter Linux bietet sich sowohl das CLI wie auch SSMS an, letzteres muss aber bis auf weiteres noch auf Windows ausgeführt werden. Als plattformunabhängige Alternative zu SSMS für Admins die kein Windows nutzen, hat Microsoft die offizielle MSSQL-Erweiterung für Visual Studio Code im Angebot, welches unter Linux, Mac und Windows eingesetzt werden kann. Dabei handelt es sich zwar nicht um einen vollständigen Ersatz für SSMS, die Lösung funktioniert aber sehr gut und bietet u.a. auch IntelliSense support.
Einschränkungen von MSSQL auf Linux
Microsoft kommuniziert sehr offen, wie es bezüglich den aktuellen Einschränkungen von MSSQL auf Linux aussieht und führt diese in den Release Notes exakt auf.
Momentan noch nicht verfügbar sind beispielsweise:
- Volltext Suche
- Replikation
- Active Directory Authentisierung
Genauere Informationen dazu findet man in den offiziellen Release Notes.
Nächste Schritte
Wir planen diverse weitere Tests und wenn es die Zeit zulässt, werden wir noch das eine oder andere weitere Thema in diesem Blog abdecken. Insbesondere interessiert sind wir am Clustering von MSSQL unter Linux, sowie dem Einsatz von MSSQL in Containern.
Fazit
Man muss Microsoft für die vorliegende Lösung ein Kränzchen winden – was die Engineers aus Redmond in Bezug auf die technische Umsetzung vorgemacht haben, hinterlässt bei uns staunende Techies.
Mit dem gewählten Ansatz ebnet Microsoft zudem den Weg für die Portierung weiterer Windows Dienste auf Linux. Schliesslich könnte SQL PAL auch für Exchange, AD, IIS, usw. Pate stehen – uns würde jedenfalls nicht erstaunen, wenn Microsoft schon 2017 verkündet, dass es nun auch Exchange für Linux gibt.
Interesse?
Haben Sie Interesse, MSSQL auf Linux zum Fliegen zu bekommen? Wir helfen sehr gerne weiter und unterstützen Sie mit unserer gesammelten Expertise bei möglichen Migrations-Projekten. Gerne treten wir mit Ihnen in Kontakt, Sie erreichen uns unter info@adfinis.com.
