SQL Server in der Microsoft Azure Cloud: PaaS gegen IaaS

    Der Weg zum Hosten von SQL Server in einer beliebigen Cloud, sei es Microsoft oder eine andere, muss mit einer sorgfältigen Planung beginnen. Architektonische Entscheidungen, die zu einem frühen Zeitpunkt des Projekts getroffen werden, können die Zukunft des Projekts völlig unerwartet beeinflussen, und dies sind möglicherweise nicht immer offensichtlich gelöste Probleme. Die Planung umfasst auch die Entscheidung, in welchem ​​Modell SQL Server gehostet werden soll - im IaaS-Modell (auf der virtuellen Maschine) oder im PaaS-Modell (wie SQL Azure DB). Der Unterschied zwischen den Modellen liegt sowohl in den Merkmalen des Technologieplans als auch im Preis, z. B. den Service Agreement Levels (SLAs) beider Modelle, dem Einfluss der Latenz sowohl in einem frühen Stadium als auch in der Phase der Freigabe, Automatisierung und vielem mehr eines Projekts.
     
    In diesem Artikel werden wir versuchen, nicht nur zu verstehen, welche technologischen Unterschiede zwischen IaaS und PaaS in Microsoft Azure bestehen, sondern auch, woher dieser Unterschied kommt, wo Probleme in PaaS auftreten können, die in IaaS möglicherweise nicht zu finden sind, und in der Architektur Diese Lösungen sowie das, was Azure SQL DB Premium ist und wann es verwendet werden soll.
     
    Inhaltsverzeichnis:
    Auswahl zwischen IaaS und Azure SQL DB
    IaaS-Methode: Allgemeine Beschreibung und Architektur
    PaaS-Methode: Allgemeine Beschreibung, Architektur und mögliche Probleme
    PaaS-Methode:
    Azure SQL DB SLA- Sicherheit - Was ist der Unterschied zu SQL Server SLA in einer virtuellen Maschine?
    PaaS Way: Hochverfügbarkeit
    Wie wähle ich den Azure SQL DB-Verwendungsmodus aus? Premium-Level - eine Garantie für die hohe Leistung von SQL Server als Dienst.
     
    Wählen Sie zwischen IaaS und Azure SQL DB ( PaaS ).
     
    In jeder Lösung, die Daten über die SQL Server-Plattform verwaltet, gibt es drei Optionen zum Hosten dieser Plattform:
    Lokal in Ihrer eigenen Infrastruktur
    Auf einer virtuellen Azure-Maschine (IaaS) )
    Als Dienst (Azure SQL DB) Das
     
    Auffinden eines lokalen Dienstes spielt keine Rolle, da er umgangen wird. In Anbetracht der beiden anderen Optionen beginnen wir sofort mit dem Entscheidungsbaum und beginnen dann, uns mit den Details zu befassen.

     
    Der erste Schritt hängt davon ab, ob Sie eine völlig neue Lösung entwickeln oder eine vorhandene migrieren. Wie oft gesagt wird, ist es einfacher, erneut zu schreiben, als sich mit der Migration der vorhandenen zu befassen, und hier ist dies möglicherweise die erste architektonische Lösung. Wenn wir ein neues Projekt haben und es noch kein Backend für die Datenverwaltung gibt, können wir sofort auf PaaS umsteigen. Durch diesen Ansatz können wir viel Zeit beim Verwalten und Bereitstellen der Infrastruktur sparen.
     
    Bei der Migration liegt eine Abzweigung vor uns. Da sich die Funktionalität von Azure SQL DB stark von der eines vollwertigen SQL Servers unterscheidet, müssen wir unsere Codebasis und Datenbank analysieren und feststellen, ob Änderungen erforderlich sind und wie kritisch sie sind. Dies ist eine sehr wichtige Abzweigung. Wenn wir den von Azure SQL DB nicht unterstützten Datentyp vermissen, verlieren wir viel Zeit und Mühe. Mit Datenbanken können wir helfensqlazuremw.codeplex.com , das die Datenbank analysieren und sagen kann, dass sie in Azure SQL DB nicht unterstützt wird. Wenn in diesem Schritt ernsthafte Änderungen an unserer Lösung erforderlich sind oder Funktionen vorhanden sind, die in Azure SQL DB nicht unterstützt werden, diese jedoch benötigt werden, bricht der Entscheidungsbaum ab und wir müssen einen lokalen SQL Server verwenden oder ihn auf einer virtuellen Maschine installieren (IaaS).
     
    Wenn wir eine neue Lösung entwickeln oder unkritische Änderungen am migrierten Projekt vornehmen können, stellt sich als nächstes die Größenbeschränkung der Datenbank in Azure SQL DB, die 500 GB beträgt. Ist das genug für uns? Was wird das projizierte Wachstum sein? Wenn wir verstehen, dass wir diese Obergrenze nicht durchbrechen werden, können wir Azure SQL DB sicher verwenden. Wenn wir verstehen, dass eines Tages eine Situation auftreten kann, in der wir 501 GB haben werden, fahren Sie mit dem nächsten Schritt fort.
     
    Можно ли перепроектировать архитектуру или реализовать шардинг собственными силами? Бывают ситуации и проекты, когда этого сделать нельзя — по разным причинам, от legacy-кода до проблем со временем. В Azure SQL DB нет механизма встроенного шардинга, поэтому его реализация ложится на плечи клиента. Если мы готовы взяться за это — то ничего не мешает нам использовать Azure SQL DB. Если нет — мы снова выходим на SQL Server на виртуальной машине или локально.
     
    Посмотрим на различия и архитектуру обоих решений.
     
    IaaSWay
     
    Метод размещения SQL Server в виртуальной машине принципиально не отличается от установки его локально, однако дьявол кроется в мелочах, и мелочах, касающихся сложной дисциплины — оптимизации. Тезисно:
     
    На виртуальную машину мы можем поставить voller SQL Server . Das Wort "voll" ist hier wichtig, da es trotz gemeinsamer Eltern funktionale Unterschiede zwischen SQL Server und Azure SQL DB gibt.
    Das Image der virtuellen Maschine befindet sich in Microsoft Azure StorageUm die Festplattenleistung zu steigern, müssen Sie diese beispielsweise zu einem RAID kombinieren. Die virtuelle Maschine in Microsoft Azure verfügt standardmäßig nicht über Datenträger, die zu einem RAID kombiniert werden können. Beim Erstellen werden zwei Datenträger empfangen, und ein Datenträger (D :) ist temporär, da er sich auf dem Datenträger des Servers befindet, auf dem der Computer gerade ausgeführt wird Das zweite (C :) wird als Blob in Microsoft Azure Storage gehostet, und alle E / A-Anforderungen werden über die Caching-Ebene gesendet. Aus diesem Grund ist die Leistung von C: immer geringer als D: D: wird jedoch während jedes Systemvorgangs von der virtuellen Maschine gelöscht (aufgrund der Übertragung auf andere physische Ressourcen). Um einen RAID zu erstellen, müssen Sie leere Datenfestplatten (auf dem Portal, Powershell und vielem mehr) erstellen und mit dem Computer verbinden.
     

     
    In Microsoft Azure sind bereits vorgefertigte optimierte SQL Server- Images (2008 R2 - 2014) verfügbar , die sowohl mit einer separat bezahlten Lizenz als auch durch Einbringen Ihrer Lizenz (unter License Mobility & Software Assurance) verwendet werden können.
    Standardisiertes Eisen. In jeder Cloud erhalten Sie standardisierte Geräte, und Sie müssen verstehen, dass diese häufig keine hochgradig abgestimmte Leistung aufweisen.
     
    PaaS Way
     
    Der PaaS-Ansatz unterscheidet sich stark von IaaS darin, dass es mehr Entwicklerabstraktionen von Infrastruktur, Einschränkungen und architektonischen Freuden gibt. Ganz unten, auf der Ebene der Infrastruktur und der Ausrüstung, handelt es sich natürlich um dieselbe standardisierte Ausrüstung. Wenn Sie also den freigegebenen Modus von Azure SQL DB verwenden, kann die Leistung bei unruhigen Nachbarn auf völlig unerwartete Weise sinken. Es gibt auch eine Reihe von Soft / Hard-Einschränkungen, die zu einem verständlichen Zweck durchgeführt werden. Wenn wir SQL Server auf einer virtuellen Maschine verwalten und uns insgesamt mit Leistungs- und Architekturproblemen befassen, wird PaaS vollständig vom Anbieter kontrolliert, und Sie müssen dies tun. damit die Lösung hoch skalierbar und belastbar ist,
     
    Gleichzeitig müssen, wie oben erwähnt, Sharding und andere Entscheidungen vom Entwickler getroffen werden. In Azure SQL DB sind noch keine Tools integriert.
     
    Berücksichtigen Sie die Architektur, um besser zu verstehen, was Azure SQL DB ist und wie es funktioniert.
     
    Das erste, was zu verstehen ist: Wenn wir den Azure SQL DB-Server erstellen, werden tatsächlich drei Server erstellt, die im Allgemeinen überhaupt keine Server sind. Dies sind Replikate, die Anforderung vom Client, an die der TDS-Einstiegspunkt weitergeleitet wird. Im Vergleich zur herkömmlichen Lösung führt IP beim Server zum Server, bei Azure SQL DB führt IP zur Infrastruktur.
     

     
    Die Anfrage wird über TDS an die Serviceschicht gesendet. Die Serviceschicht ist das Gateway zwischen dem Client und der Plattformschicht. Hier finden Sie die allgemeinen Dienste unserer Azure SQL-Datenbank: Bereitstellung von Ressourcen, Abrechnung verbrauchter Ressourcen, Abfragerouter und vieles mehr.
     
     

     
    Darüber hinaus wird die Anforderung an die Plattformschicht weitergeleitet, auf der Infrastrukturdienste ausgeführt werden. Dies bietet die unmittelbare Funktionalität von SQL Server als Dienst. Dies ist die letzte Abstraktionsebene über der Infrastruktur, unten nur die Ausrüstung.
    Wie Sie auf dem Bild sehen können, ist die Architektur der Azure SQL DB-Lösung viel komplizierter als das Hosten von SQL Server in einer virtuellen Maschine. Lastausgleich und Replikation funktionieren auch auf jeder Ebene, und all dies funktioniert automatisch ohne menschliches Eingreifen.
    Mit einer solchen Architektur unterscheidet sich der Ansatz zur Lösung neu auftretender Probleme etwas von dem, an den wir bereits gewöhnt sind. Es gibt weniger Tools für die Diagnose, daher ist es wichtig zu verstehen, was dieses oder jenes Problem verursacht. Wenn wir über die häufigsten Probleme sprechen, können die Ursachen für deren Auftreten auf Azure SQL DB-Ebenen platziert werden. Die erste Ebene der Probleme tritt bereits auf der Ebene der TDS-Kommunikation auf. Hier haben wir mehr Latenz als bei der lokalen Bereitstellung und verschiedene Arten von Schwankungen - hauptsächlich vor dem Eintritt in die Azure SQL DB-Infrastruktur, dh auf Netzwerkautobahnen, die nicht mit Microsoft zusammenhängen. Dieser Punkt ist wichtig, da die Anforderung möglicherweise mit einem Timeout zurückgegeben wird und dies durch die Entwicklung und Planung der Wiederholungslogik abgedeckt werden muss.
     

     
    Wenn die Anforderung bereits bei der Infrastruktur angekommen ist, wird sie intern überprüft und die Anmeldung erfolgt zusammen mit anderen Anforderungen für dieses Gerät über ein Gateway. Dann wird die Verbindung geöffnet, es kann jedoch auch hier zu einer Zeitüberschreitung kommen, wenn der Vorgang nicht rechtzeitig abgeschlossen wird - und dies sollte auch durch eine Wiederholungslogik gelöst werden.
    Während der Arbeit von Azure SQL DB selbst besteht eine konstante Wahrscheinlichkeit von Problemen auf Plattformebene. Hier gelten alle vom Hersteller für Azure SQL DB auferlegten Einschränkungen. Wenn sie überschritten werden, wird der entsprechende Fehler an den Client zurückgegeben. Hier können wir nichts tun, die einzige Möglichkeit ist, diese Fehler auf der Client-Seite zu behandeln (Liste der Fehler -msdn.microsoft.com/en-us/library/ff394106.aspx ).
    Wenn wir die Verwendung von Azure SQL DB zusammenfassen, müssen wir die folgenden Situationen verstehen und behandeln:
     
    Der Client sollte geografisch nicht weit von Azure SQL DB entfernt sein. Wenn sich der Client lokal bei uns befindet, müssen wir verstehen, dass wir konstante Schwankungen in den Netzwerk-Backbones haben, und eine angemessene Verarbeitung für diese Schwankungen und Situationen mit Timeout-Fehlern implementieren. Eine gute Option besteht darin, den Client so nahe wie möglich an der Azure SQL-Datenbank in der Cloud zu platzieren.
    Für Azure SQL DB gelten Einschränkungen , die aus einem bestimmten Grund eingeführt werden. Wenn wir bequem arbeiten möchten, sollten wir nicht berücksichtigen, wie viel sie geben, sondern wie viel wir benötigen, und berücksichtigen, dass der Verbindungspool nicht aus Gummi besteht.
    Merkmale der Mandantenfähigkeit. Nirgendwo erhalten wir Leistungsgarantien, wenn Ressourcen zwischen Kunden geteilt werden. Hier entsteht im Fall von Azure SQL DB der Premium-Modus, in dem wir reservierte Ressourcen erhalten, die wir frei verwenden können, und sicher sind, dass niemand sie abholt, wenn sie nicht verwendet werden.
     
    Wir haben untersucht, wie sich die Architektur unserer PaaS-Lösung von der IaaS-Lösung unterscheidet. Wie bereits erwähnt, ist die PaaS-Architektur technologisch komplexer, da der Client im Automatikmodus mit Fehlertoleranz, schneller Bereitstellung und vielem mehr ausgestattet und gleichzeitig auf eine große Anzahl von Clients gelegt werden muss. Mit der Komplexität der Architektur kommt jedoch auch eine komplexere Diagnose von Problemen, Einschränkungen und Unterschieden mit Standard-SQL Server.
    Lassen Sie uns nun einen weiteren wichtigen Aspekt betrachten - die Azure SQL DB-Sicherheit. Über die Sicherheit virtueller Maschinen und damit von SQL Server in ihnen wird hier geschrieben:blogs.msdn.com/b/albe/archive/2014/04/21/azure.aspx
     
    PaaSWay: безопасность
     
    Azure SQL DB имеет набор отличий от локального SQL Server, и самые существенные из них касаются вопросов безопасности. Учитывая особенности реализации любого программного продукта, который предоставляется как сервис (то есть, по факту, предоставляет серьезный уровень абстракции от большого количества инфраструктурных задач), необходимо четко понимать, как работает SQL Azure, чтобы иметь представление о том, почему та или иная функциональность может быть пока не поддерживаемой.
     
    Wie bereits geschrieben, verwenden SQL Azure-Datenbanken das Standardprotokoll für den tabellarischen SQL Server-Datenstrom (TDS), jedoch ist ausschließlich verschlüsselte Kommunikation zulässig. In SQL Server 2008 wurde eine neue Funktion eingeführt: die transparente Datenverschlüsselung (TDE), mit der Sie Daten mit minimalem Aufwand vollständig verschlüsseln können. Derzeit unterstützt SQL Azure-Datenbanken jedoch keine Verschlüsselung auf Datenbankebene. Es ist zu beachten, dass Azure SQL DB derzeit nur über TCP-Verbindungen und nur über Port 1433 verfügbar ist. Daher müssen die ADO.NET-Verschlüsselungsfunktionen und -Zertifikate berücksichtigt werden. Beispielsweise schützen die Eigenschaften der Verbindung Encrypt = True und TrustServerCertificate = False die übertragenen Daten und verhindern Man-in-the-Middle-Angriffe. Der zweite Schutz von Azure SQL DB und Im Allgemeinen ist die Azure SQL DB-Firewall die Hauptsache, die zunächst den gesamten Zugriff auf den Server blockiert. Versuche, eine Verbindung zu den entsprechenden Einstellungen herzustellen, schlagen fehl. Um mit dem Azure SQL DB-Server zu arbeiten, müssen Sie das Azure SQL DB-Portal aufrufen und die Firewall-Einstellungen für den Zugriff auf Ihren Server festlegen. Die Azure SQL-Firewall kann über das Azure SQL DB-Portal oder direkt in der Hauptdatenbank mithilfe gespeicherter Prozeduren wie sp_set_firewall_rule und sp_delete_firewall_rule verwaltet werden.
     
    Wie bei jeder SQL Server-Implementierung ist die Benutzerkontenverwaltung ein weiterer Aspekt, der streng kontrolliert werden muss.
    Im Sicherheitskontext gibt es eine Liste von Unterschieden zwischen SQL Server- und SQL Azure-Datenbanken:
    Microsoft SQL Server unterstützt die integrierte Windows-Authentifizierung mithilfe von Zugriffsparametern aus Active Directory. SQL Azure-Datenbanken unterstützen nur die SQL Server-Authentifizierung.
    Microsoft SQL Server- und SQL Azure-Datenbanken verwenden dasselbe Berechtigungsmodell, das auf Benutzern und Rollen basiert, die in jeder Datenbank erstellt und mit Benutzeranmeldungen verknüpft sind.
    Microsoft SQL Server verfügt über Standardrollen auf Serverebene, z. B. serveradmin, securityadmin und dbcreator. SQL Azure-Datenbanken haben diese Rollen nicht. Stattdessen haben SQL Azure-Datenbanken die Rollen des Anmeldemanagers (Erstellen von Anmeldungen) und des Datenbankmanagers (Erstellen und Verwalten von Datenbanken). Diese Rollen können Benutzern in der Master-Datenbank zugeordnet werden.
    Der Zugriff auf SQL Server und Azure SQL DB erfolgt über das Anwendungsschichtprotokoll Tabular Data Stream (TDS), das durch SSL geschützt ist, über den TCP / 1433-Port. Die Verwendung von SSL ist für Microsoft SQL Server optional und für Azure SQL DB erforderlich.
    In SQL Server muss die IP-basierte Zugriffssteuerung auf Host- oder Netzwerkebene mithilfe von Firewalls erfolgen. Azure SQL DB verfügt über eine integrierte Firewall, die den gesamten Zugriff auf den Azure SQL DB-Server einschränkt, um festzustellen, welche Clients autorisierte Computer sind. Die Firewall gibt den Zugriff basierend auf der IP-Adresse jeder Anforderung aus.
    SQL Server bietet eine Echtzeitverschlüsselung aller gespeicherten Daten auf Seitenebene mithilfe der TDE-Funktion (Transparent Data Encryption). TDE wird in Azure SQL DB nicht unterstützt .
    Azure SQL DB verfügt über einen integrierten DDOS-Schutz. In SQL Server gibt es keine.
    Azure SQL DB patcht und aktualisiert automatisch ohneAusfallzeiten. SQL Server muss aktualisiert werden, was zu Ausfallzeiten führen kann.
     

     
    Es gibt also Sicherheitsunterschiede, die behoben werden müssen. Manchmal ist der Blocker das Fehlen von TDE, manchmal nicht - alles hängt von der Entscheidung ab. Und im nächsten Block schlage ich vor, die Unterschiede in der SLA zu untersuchen.
     
    Azure SQL DB SLA - Was ist der Unterschied zu SQL Server SLA in einer virtuellen Maschine?
     
    SLA ist ein wesentlicher Bestandteil jeder kommerziellen Bereitstellung. Ein Azure SQL DB-SLA ist detaillierter als ein SQL Server-SLA in einer virtuellen Maschine, da das SLA direkt für den Azure SQL DB-Dienst bereitgestellt wird und im Fall von IaaS nicht für die zugrunde liegende Infrastruktur und virtuelle Maschine (jedoch nicht für SQL Server). Dies ist von grundlegender Bedeutung. Die SLA in Azure SQL DB beträgt 99,9%. Dies bedeutet 10 Stunden Ausfallzeit pro Kalenderjahr, die für die Wartung des Dienstes benötigt werden. Der Kundendienst wird im Voraus gewarnt.
     
    Way PaaS: Hohe Verfügbarkeit
     
    Azure SQL DB wird anfänglich unter Hochverfügbarkeit erstellt, und alle Architekturkomponenten sind fehlertolerant. Es ist wichtig zu verstehen, dass die HA-Standardkonzepte für SQL Servr nicht auf Azure SQL DB anwendbar sind (wiederum aufgrund von Architekturunterschieden). In Azure SQL DB gibt es Mechanismen, die alle Datensätze in drei Replikaten auf verschiedene Server replizieren, wodurch eine SLA von 99,9% bereitgestellt wird. Gleichzeitig ist ein Replikat primär - es wird ein Schreibvorgang ausgeführt, und wenn dies bestätigt wird, wird alles synchron zu sekundären Replikaten repliziert.
     
    Wenn wir Azure SQL DB selbst replizieren möchten, macht sich niemand die Mühe, dies beispielsweise mit Data Sync zu tun.
     

     
     
    Wie wähle ich den Betriebsmodus von Azure SQL DB aus?
     
    Ab April 2014 wurden die Azure SQL DB-Betriebsmodi geändert. Die alten Web- / Business-Modi wurden abgebrochen, wobei der Schwerpunkt auf der Größe der Datenbank lag, während sich die neuen Modi Basic / Standard / Premium vollständig auf die Bereitstellung von Leistungsgarantien konzentrierten. Die Abbildung zeigt einen einfachen Entscheidungsbaum, welcher der neuen Modi unter welchen Bedingungen verwendet werden soll. Sie müssen jedoch verstehen, dass der Premium-Modus trotz der Bereitstellung eines bestimmten Leistungsniveaus durch die Basis- / Standardmodi durch erhöhte Werte aller Indikatoren gekennzeichnet ist - ausgehend von der Tatsache, dass die Basis im Premium-Modus bis zu 500 GB betragen kann und mit vielen garantierten Eisenressourcen endet mehr als in Basic / Standard. Wenn Sie also vorhaben, eine Lösung in Azure SQL DB zu hosten, die sehr ressourcenintensiv ist und
     
     
     

     
    Eine separate Überprüfung erfordert den Premium-Modus. Es ist, wie bereits erwähnt, für Projekte gedacht, die ein garantiert hohes Maß an Produktivität erfordern. Um diese Leistung zu bewerten, wurde ein spezieller Test-Azure SQL-Datenbank- Benchmark entwickelt
    (Berechnen der in verschiedenen OLTP-Aufgaben verwendeten Werte. Die Ressourcen und die Leistung der einzelnen Modi und Leistungsstufen in Azure SQL DB-Benchmark werden in DTU (Database Throughput Units) ausgedrückt. DTU bietet eine Möglichkeit, die relative Leistungsstufe basierend auf CPU-, Speicher- und R / W-Vorgängen zu messen Das Verdoppeln der DTU bedeutet also praktisch das Verdoppeln der Leistung der für die Basis zugewiesenen Ressource. Der Azure SQL DB-Benchmark-Test berücksichtigt auch die Transaktionsrate, die in Transaktionen pro Einheit ausgedrückt wird, während die Zeit für leistungsfähigere Modi verkürzt wird (Basis - um eine Stunde, Standard - n und Minuten und Premium ermöglicht es Ihnen, eine große Anzahl paralleler Transaktionen pro Sekunde durchzuführen) und Vorhersagbarkeit oder eine Garantie für die Antwortzeit.
    In diesem Test ist Premium der leistungsstärkste Modus. Im einfachsten Basismodus mit 1 DTU verfügt der Premium P3-Level über 800 DTU, dh 800-mal leistungsstärker, und die Leistungsgarantie wird ebenfalls erhöht.
     
    Weitere Informationen zu den neuen Betriebsmodi von Azure SQL DB finden Sie auf der offiziellen Seite.msdn.microsoft.com/en-US/library/azure/dn741340.aspx
     
    Zusammenfassung
     
    SQL Azure Datenbanken - SQL Server in PaaSModus. Aufgrund seiner Einschränkungen und seiner Funktionen, die in SQL Server nicht verfügbar sind (hauptsächlich im Zusammenhang mit Fehlertoleranz und Automatisierung von Aufgaben wie dem Lastausgleich), kann SQLAD ein Tool sein, das anstelle der lokalen Bereitstellung verwendet wird, um von Infrastrukturaufgaben zu abstrahieren. Es ist jedoch wichtig und notwendig verstehen, dass die bestehenden Einschränkungen die Diskussions- und Planungsprozesse des entwickelten Projekts ernsthaft beeinträchtigen sollten. Es ist unmöglich eindeutig zu sagen, welcher Ansatz (IaaS oder PaaS) ab und zu besser sein wird, aber die im Artikel dargestellten Daten und Gedanken können in dieser Angelegenheit hilfreich sein.
     

    Jetzt auch beliebt: