none
Fallstricke / Änderung bei SQL 2014-2017-2019-Lizenzmodell: Welche Lizenz/Software macht Sinn wenn man nur die BI-Tools nutzen möchte? RRS feed

  • Frage

  • Hallo zusammen,

    ich möchte hier kurz die Servermodelle und Nutzung des SQL-Servers zzgl. SSRS vergleichen: 

    1.)Szenario SQL-Server 2014: In der Vergangenheit wurde mir ein SQL-Server 2014 mit 30Cals zur Verfügung gestellt. Die Kosten waren meine ich bei einmalig 5000eur schaubar und die Lizenz-Prüfung durch Microsoft war anstandslos. Microsoft war bei der BI-Nutzung jedoch hellhörig und fragte, ob es Verbindungen zu anderen Servern durch die ETL-Prozesse gab. Die ETL-Prozesse liefen aber nur auf CSV-Dateien. Die möglichen Auswirkung auf die Lizenzkosten durch die ETL-Prozesse habe ich jedoch nicht verstanden.

    2.) Szenario SQL-Server 2017/2019:Der SQL-Server läuft auf einem DELL Server mit 32 Kernen im Cluster. Der BI-Server 2017/2019 soll mit 4 Kernen ausgestattet werden. Jetzt kommt die Information, dass die Serverlizenzkosten regelrecht explodieren. Bei CPU-Lizenzen (keine Cals) brauche ich 2 x 16 x 3.680Eur. Bei CAL-Lizenzen sind es auch 2 x 16 x 980Eur zzgl. 30 CAL je 180eur? Ich kaufe also das Hochhaus und brauche nur eine Wohnung?

    Alternative 1:
    Wenn man bspw. einen SQL-Server 2017 hätte nutzt man einfach eine weitere Instanz und kauft keinen neuen Server? ....aber wie ist dies im Unternehmensverbund bei 2 rechtlich getrennten Firmen und Domänen möglich?

    Alternative 2:
    Dadurch, dass die BI-Datendaten redundante Daten sind, diese nur 1x täglich aktualisiert werden und auch die Verfügbarkeit "unkritisch" ist, die Frage, ob man hier nicht einfach einen guten PC als BI-Server ins Netz einbindet und aufbaut? Hier natürlich die Frage wie man hier ggf. die Rechtenutzung (@User=DOMÄNENNAME\User) nutzen kann und wie es sich mit der Performance u.a. verhält und was ev. für weitere Fallstricke bestehen.

    Alternative 3: Reportbuider als "Kostenlose" Software autark mit einem anderen Server bzw. SQL-Express nutzen? Damit wäre zwar Reports weiter nutzbar, aber die SSRS-Umgebung nicht.

    Hat sich hier beim Lizenzmodell 2014=>2017=>2019 so viel geändert bzw. welcher Server/Umgebung macht in dem genannten Umfeld Sinn?

    Leider sind die Aussagen oft widersprüchlich und das Lizenzmodell von Microsoft scheinbar sehr volatil und bei den oben genannten Kostenexplosionen stellt man sich die Frage, ob man weiter bzw. langfristige auf den SQL-Server setzen sollte, wenn man diesen nur als BI-Server nutzen möchte bzw. den Berichtsgenerator. Der Reportbuider wäre doch auch autark nutzbar?

    Vielen Dank für Euer Feedback zur den oben genannten Konstellationen.

    Mittwoch, 21. Oktober 2020 10:18

Alle Antworten

  • Grundsätzlich gilt: egal mit welcher Anwendung du mit einem SQL-Server arbeitest, das Lizenzmodell ist immer identisch.
    Auch wenn du nur Power-BI machst, greifen die User eben auf den SQL-Server zu und das kostet.

    zu 1):

    Wenn ein ETL-Prozess auf einen anderen SQL-Server zugreift, ist dort eine User-CAL erforderlich, wenn nicht bereist durch Enterprise abgedeckt.

    zu 2):

    Das ist korrekt. Es wird immer die Hardware lizensiert. Wenn du eine BI-VM mit 4 CPU's installierst aber auf 16-Kern Hardware läuft, müssen 16 Kerne lizensiert werden. Dafür darfst du aber beliebig viele SQl-Server einsetzen (auch wenn du sie nicht brauchst).

    Alternative 1)
    Jede Firma benötigt eigene Lizenzen da ein durchreichen von Lizenzen nicht erlaubt ist.

    Alternative 2 und 3 sind gelichwertig zu sehen.
    Da der SQL-Server lizensiert wird und nicht die Anwendung kannst du nur einen kleinen PC mit z.B. 1/2 Cores nehmen um die Lizenzen zu reduzieren.

    Hier reicht u.U. schon ein SQL-Sever Standard. Wenn die Anzahl der Abfragen nicht allzu groß  sind kommt der damit gut zurecht.
    Express ist aus Performancegründen nicht empfehlenswert, da hier nur max. 1GB Speicher verwendet wird selbst wenn man erheblich mehr hat.

    User Cals sind für jeden BI-User natürlioch erforderlich.

    Bei den Lizenzen gibt es noch den Begriff der Passthru-Nutzung.
    Wenn also ein User die Daten der DB2 durch eine Instanz der DB1 mit nutzt, ist ein User-Cal auf beiden DB's erforderlich.

    Dies gilt auch für CSV-imports.
    SQL-Server1 - CSV-Export => SQL-Server2 CSV.-Import

    Dieser Umweg löst nicht das Lizenzproblem, da der Import via Verbindungsserver auch möglioch wäre.

    Befindet sich alles auf derselben Hardware, benötigst du nur User-Cals für 1 Hardware, ansonsten je Hardware.

    Und was deinen Hochhaus-Vergleich angeht, so hast du recht:
    Die Hardware ist das Hochhaus, die VM ist die Wohnung.
    Grund- und Erwerbssteuer zahlst du auf das Gesamtobjekt.
    Mittwoch, 21. Oktober 2020 11:03
  • Moin,

    das Lizenz*modell* hat sich nicht geändert, die Features wurden zwar teilweise "nach unten" umverteilt, aber in Deinem Fall ist es vermutlich unerheblich.

    Zwei Dinge:

    1. Für die Standard Edition, wenn sie vom Funktionsumfang her reicht, gibt es ein Server+CAL- und alternativ ein Core-Modell. Im Server+CAL-Modell sind die Kerne egal, im Core-Modell sind die User egal. Für die Standard gibt es ein hartes Limit von 24 Kernen, die durch eine Instanz technisch beansprucht werden können.
    2. Für die Enterprise Edition gibt es nur das Core-Modell und keine CALs.

    Welche Edition Du brauchst, ergibt sich aus den Features. Das war vermutlich der Hintergrund der Frage nach anderen Servern - wenn Du SSIS mit Oracle, DB2 oder SAP-DB betreiben möchtest, bist Du bei Enterprise.

    Wenn Du im Core-Modell lizenzierst, hast Du drei Möglichkeiten:

    1. Du installierst Dein SQL auf Blech. Dann musst Du in der Tat alle Cores lizenzieren, die in diesem Blech vorhanden sind. Dafür kannst Du so viele Instanzen haben (bis zu 50) wie Du möchtest und damit halt auch das 24-Core-Limit der Standard quasi umgehen, wenn Du so viel Bums brauchst.
    2. Du installierst Dein SQL Standard in einer VM. Dann kannst Du die vCPUs dieser VM lizenzieren, mit einem Minimum von 4 Stück. Damit darfst Du die VM aber nicht bewegen, außer Du hast SA.
    3. Du installierst Dein SQL Enterprise in einer VM. Dann kannst Du entweder genau so verfahren wie bei Standard, oder Du lizenzierst alle Kerne im Host und kannst dann beliebig viele solcher SQL-VMs auf diesem Host fahren.

    Evgenij Smirnov

    http://evgenij.smirnov.de


    Mittwoch, 21. Oktober 2020 11:52
  •  Reportbuider als "Kostenlose" Software autark mit einem anderen Server bzw. SQL-Express nutzen? Damit wäre zwar Reports weiter nutzbar, aber die SSRS-Umgebung nicht.

    Apropos: je nachdem, wie aufwendig Dein SSRS-Bedarf ist, kannst Du eine SSRS-Umgebung komplett mit SQL Express aufziehen: https://docs.microsoft.com/en-us/sql/reporting-services/reporting-services-features-supported-by-the-editions-of-sql-server-2016?view=sql-server-ver15

    Allerdings dürfen die Datenquellen dann auch nur aus einer Express kommen...


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 21. Oktober 2020 12:46
  • Hallo zusammen,

    vielen Dank für die Antworten! 

    Jetzt nochmal zusammengefasst für mein Verständnis:

    1.) Wenn ich auf einem Blechserver mit 16 Kernen im Cluster installiere wird es richtig teuer

    2.) Wenn ich eine VM mit dem 16 Kern-Blechserver  für 4 Kernen einrichten lasse, kann ich mit 2x2 Core-Lizenzen so viel User auf den Server zugreifen lassen wie ich möchte und alles wäre für 2x3.680eur erledigt?

    3.) Wenn der ETL-Prozess bspw. bei der Quelle über eine angelegte ODBC-Schnittstelle auf eine Informix-DB und My-SQL-Server Datenbank und CSV-Datein zugreift muss ich ohnehin eine bzw. 2 Enterprise-Lizenzen kaufen oder mir die Daten als CSV-datei ablegen lassen, was wieder richtig teuer wird!? Daher war Microsoft bei der Prüfung auch so hellhörig wie die ETL-Datenverläufe sind? Mit nur nur abgelegte CSV-Dateien komme ich mit den 2x2 core-Lizenzen klar was lt. "Der Suchender" ein umgehen ist.

    Mir ist das mit dem Passtrough nicht klar. Ich kann doch auch in Excel oder aus Access Daten ziehen die ich manuell vom Server abgetippt habe oder Daten die ich manuell als Stammdaten pflege oder aus einer Accessdatenbank von der DATEV-Kostenrechnung ziehe. Eine CAL wäre verständlich aber warum die Enterprise-Version. Dies ist mir leider nicht klar.

    Vielen Dank nochmal für eure Erläuterungen!

    Mittwoch, 21. Oktober 2020 15:15

  • Mir ist das mit dem Passtrough nicht klar.

    Das ist ein Sachverhalt, der sich nur auf die CAL-Lizenzierung bezieht und am besten mit einem Beispiel illustriert ist:

    • Stellen wir uns mal vor, der zu lizenzierende SQL-Server befeuert eine Citrix-Farm. Diese hat zwei Desktop Delivery Controller und einen Service-User, mit dem die Citrix-Dienste dort laufen.
    • Auf die SQL-Datenbanken wird also von maximal zwei Maschinen mit maximal einem User-Account tatsächlich zugegriffen.
    • Dennoch ist jeder potentielle User dieser Citrix-Farm mit einer SQL-User-CAL zu versehen, da die Funktionalität, die er benutzt, erst durch diese SQL-Datenbank ermöglicht wird.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 21. Oktober 2020 15:53
  • 1.) Wenn ich auf einem Blechserver mit 16 Kernen im Cluster installiere wird es richtig teuer

    Das kommt darauf an, ob Du eine Bank bist oder ein gemeinnütziges Krankenhaus.

    2.) Wenn ich eine VM mit dem 16 Kern-Blechserver  für 4 Kernen einrichten lasse, kann ich mit 2x2 Core-Lizenzen so viel User auf den Server zugreifen lassen wie ich möchte und alles wäre für 2x3.680eur erledigt?

    Mit Deinen EUR-Preisen kann keiner was anfangen, denn niemand kriegt dieselben Preise. Aber ja, in etwa kommt es hin (https://www.microsoft.com/de-de/sql-server/sql-server-2019-pricing) wenn Dir die Standard Edition von den Features her genügt.

    3.) Wenn der ETL-Prozess bspw. bei der Quelle über eine angelegte ODBC-Schnittstelle auf eine Informix-DB und My-SQL-Server Datenbank und CSV-Datein zugreift muss ich ohnehin eine bzw. 2 Enterprise-Lizenzen kaufen oder mir die Daten als CSV-datei ablegen lassen, was wieder richtig teuer wird!? Daher war Microsoft bei der Prüfung auch so hellhörig wie die ETL-Datenverläufe sind? Mit nur nur abgelegte CSV-Dateien komme ich mit den 2x2 core-Lizenzen klar was lt. "Der Suchender" ein umgehen ist.

    Wenn das gebende System die Daten zum Nulltarif in SQL oder CSV schreiben kann, kannst Du mit einer Standard darauf zugreifen. Wenn Die SQL-Instanz auf Fremd-Datenbanken zugreifen will, ist es Enterprise.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 21. Oktober 2020 15:58
  • 1+2 ist Identisch:

    a) du lizensierst das Blech. Da gibts 2 Modelle: a) Coremodell = User unlimmited, b) User-Modell, also User-CAL. Bei 100 Usern wirds auch schon teuer.
    D.h., beim Core-Modell eben 16x.
    User-Lizenzen sind auch nicht übertragbar. D.h., hast du 2 SQL-Server mit User-CAL's und ein User arbeitet mit beiden, benötigst du auch 2 User-CAL's.

    ETL mit SSIS zu fremden DB's ist das Problem. Machst du die Importe selber, also mit einem kleinen Programm so wie ich, ist das wieder egal.

    Klar kannst du mit Excel oder Access Daten auslesen, dafür brauchst du aber eine User-CAL oder eine Core-Lizenz.

    Passthru ist z.B. folgendes Konstrukt:
    Du hast eine Web-Anwenwendung für 1000de User, um aber nicht jeden User zu registrieren, arbeitet der Server, der ja den SQL-Zugriff macht, mit einem eigenen Profil. Dies ist deine Durchleitung (Passthru).
    Die Ausnahme ist dann, wenn du nachweislich einen Web-Shop betreibst.

    Mittels Passthru kann man sich eben viele Methoden ausdenken, statt Web-Server einen Server-Dienst via Messaging usw. Alles Passthru und lizenzpflichtig.

    Wir sind gerade deswegen mit unserer Anwendung schon längst auf Firebird (Opensource) gegangen. Das ist kostenlos, kann die DB auf mehrere Platten verteilen (Partitionon) und auf andere Platten spiegeln (z.B. für Lesezugriffen). Die FB hat auch keinerlei Enschräkungen bzgl. Speicher und Anzahl DB's.
    Unsere BI-Suite lädt per Import aus jeder Datenbank in die Firebird (nun ja, Eigenwwerbung).

    Außerdem so teuer wirds doch nicht, der Breakeven liegt doch schon bei nur ca. 350 Usern
    Mittwoch, 21. Oktober 2020 16:04
  • Nochmal kurz zum ODBC-Zugriff, hier fehlt mir noch die Kurve:

    Grundsätzlich bietet die Standardversion den ODBC-Zugriff ja an. Warum ist dieser dann mit bei Nutzung zu anderen Datenbanken auf Enterprise zu lizensieren? Wo finde ich den Lizensierungshinweis dazu? 

    In meinem Fall: Die abgebende Datenbank bietet mir doch den OBDC-Treiber und stellt mir die Daten doch dann per SQL-Statement in Visual Studio ETL-Prozess zur Verfügung? Ich muss im Vorfeld die Treiber und Einrichtung ja auf dem Server vornehmen damit dies geht. Wenn ich jetzt aus Access und Excel Daten ziehe ist es doch ähnlich, wobei ich hier den interne Treiber nehme? 

    Vielen Dank für Euer Erläuterungen und Hinweise.


    Mittwoch, 28. Oktober 2020 15:07
  • Der ODBC kostet ja auch nichts.
    Per Definition will Microsoft aber eben Lizenzgebühren wenn du vom SQL-Server direkt auf andere Datanbanken zugreifen willst.
    Export CSV <-> Import CSV ist ja kein Direktzugriff und deshalb Lizenzfrei.

    Wenn du mit Access/Excel Daten aus Datenbanken lädst, brauchst du ja auch Lizenzen von Access/Excel/Office und der jeweiligen Datenbank.

    Nix is ömesönst.

    Mittwoch, 28. Oktober 2020 15:13
  • ...genau darum geht es. Wo steht die Definition in den Lizenzrechten. Alle Distributor sagen ODBC ist kein Lizenz-Problem bei der Nutzung.

    Also: Excel und Access habe ich lizensiert. Mit Excel selber komme ich jedoch auch nicht auf die Fremddatenbank, sondern nur wenn ich den hauseigenen ODBC-Treiber der Fremddatenbank lokal installiert habe. Den Treiber bekomme ich nur, wenn ich die Fremddatenbank lizensiert habe. Zahle ich damit die Nutzung nicht doppelt? Unter direkt würde ich verstehen, wenn ich direkt aus der SQL-Datenbank die ODBC-Boardmittel nutze.

    Dann könnte ich über VBA in Access mit dem ODBC-Treiber die Dateien wegschreiben bzw. als CSV-Datei zur Verfügung stellen und dann auf den SQL-Server per ETL importieren oder verstößt man hier auch gegen andere MS-Lizenzrechte? 

    Mittwoch, 28. Oktober 2020 15:54