IBM SOFTWARE Nachlizenzierung muss nicht sein. Dr. Johannes Engel Intero Consulting GmbH

Transkript

1 IBM SOFTWARE Nachlizenzierung muss nicht sein Dr. Johannes Engel Intero Consulting GmbH

2 Inhalt Teil 2: IBM richtig lizenziert Lizenzmetriken und deren Gefahren hinsichtlich Compliance Virtuelle Umgebungen professionell lizenziert Optimale projektspezifische Lizenzierung an Praxisbeispielen

3 Agenda 1. Lizenzierungstypen im Detail Host (System z) Open Systems (Unix, Windows, etc.) 2. Sonderthemen und Diskussion

4 Lizenzierungstypen Host Übersicht Lizenzierungstypen im z/os-umfeld Kaufsoftware One Time Charges (OTC) beinhaltet eine in der zeitlichen Nutzungsdauer unbegrenzte Lizenz Optional können jährliche Wartungsleistungen hinzugekauft werden Analog zum PPA-Umfeld wird Software auf das Unternehmen lizenziert, kann also beliebig zwischen verschiedenen Maschinen verschoben werden Mietsoftware Monthly License Charges (MLC) wird über eine monatliche Mietgebühr abgerechnet Die Lizenzierung erfolgt auf eine konkrete Maschine (Seriennummer) Abgerechnet wird je Sysplex Die Gebühren bemessen sich an der tatsächlichen Nutzung (rollierender 4-Stunden-Durchschnitt) Diese wird erfasst über die sogenannten SCRT-Reports, die sich der Kunde verpflichtet monatlich abzuliefern

5 Agenda 1. Lizenzierungstypen im Detail Host (System z) Open Systems (Unix, Windows etc.) 2. Sonderthemen und Diskussion

6 Lizenzierungstypen Open Systems Übersicht Lizenzierungstypen im PPA-Umfeld Kaufsoftware 1. Jahr: Kauf der entsprechenden Lizenz inkl. Software-Wartung für ein Jahr berechtigt zur zeitlich unbegrenzten Nutzung der Software sowie zum Bezug von Updates und Unterstützung im ersten Jahr Folgejahre: Kauf der Software-Wartung für alle genutzten Lizenzen des Produkts berechtigt zum Bezug von Updates und Unterstützung im laufenden Jahr Mietsoftware 1. Jahr: Kauf der Initial Fixed Term License inkl. Software-Wartung für ein Jahr berechtigt zur Nutzung der Software sowie zum Bezug von Updates und Unterstützung im ersten Jahr Folgejahre: Kauf sog. Subsequent Fixed Term License inkl. Software-Wartung für jeweils ein Jahr berechtigt zur Nutzung der Software sowie zum Bezug von Updates und Unterstützung im jeweiligen Jahr

7 IBM PPA Lizenzen und Wartung Im Bereich des IBM Passport-Vertrags unterscheidet man: das Nutzungsrecht, d.h. die eigentliche Lizenz (License) Wartung, genauer Subscription (das Upgrade-Recht) und Technischer (Hersteller-)Support (bei Fehlern) PPA-Artikel treten typischerweise in folgenden Formen auf: License, Subscription and Support: Lizenz inkl. 12 Monate Wartung Sonderformen: Trade-up-Lizenz = Umstieg auf eine höherwertige IBM-Lizenz Competitive Trade-up: Eintauschen einer Fremdlizenz Software Subscription & Support Renewal: Verlängerung der Wartung für 12 Monate (Ausnahme: Anpassung an den Jahrestag) Software Subscription & Support Reinstatement: Wiederaufnahme bereits abgelaufener Wartung für 12 Monate

8 Lizenzierungstypen Open Systems Übersicht der häufigsten Lizenzmetriken Nutzerbasiert Kapazitätsbasiert Verwaltete Systeme Sonstige Authorized User Processor Value Units (PVU) Client Device MSU per hour Server Resource Value Units (RVU) Virtual Server Managed Processor Install Millions of Service Units (MSU) Terabyte Proprietäre Lizenzierungen zugekaufter Produkte (bspw. FileNet, ILog) Concurrent User Floating User Authorized User Value Units Employee User Value Units External User Value Units Value Units (VU) Sonderformen (z.b. Token)

9 Agenda 1. Lizenzierungstypen im Detail Host (System z) Open Systems (Unix, Windows etc.) 2. Sonderthemen und Diskussion

10 Sonderthemen Sonderthemen Themensammlung: Lizenzprüfung durch IBM (Audit) Einsatz und Funktionsweise des ILMT Lizenzierung von Test- und Entwicklungsumgebungen Lizenzierung von Cluster-Umgebungen Vertragsformen und deren Besonderheiten (OIO, ESSO, BaU)

11 LICEN A 2016 Kontakt Dr. Johannes Engel Intero Consulting GmbH Partner phone: mobile: j.engel@intero-consulting.de web: intero-consulting.de

12 Backup

13 Lizenzierungstypen Open Systems Nutzerbasierte Lizenzierung Typ Beschreibung Authorized User Jede Lizenz ist dauerhaft einer Person (Nutzer) zugeordnet Concurrent User Jede Lizenz berechtigt zur gleichzeitigen Nutzung einer Instanz des Programms durch einen Nutzer (mehrere Instanzen werden mehrfach gezählt) Floating User Jede Lizenz berechtigt zur gleichzeitigen Nutzung beliebig vieler Instanzen des Programms durch einen Nutzer (mehrfache Instanzen werden nur einfach gezählt) Authorized User Value Units (AUVU) Wie Authorized User, nur dass hier mit steigender Nutzerzahl weniger Lizenzen pro Nutzer benötigt werden Employee User Value Units (EUVU) Wie AUVU, hier müssen aber Lizenzen für alle Mitarbeiter eines Unternehmens erworben werden External User Value Units (XUVU) Wie AUVU, im Gegensatz zu EUVU aber für unternehmens-fremde Nutzer (bspw. Kunden)

14 Lizenzmetriken im PPA-Umfeld User-basierte Lizenzierung Authorized / Named User Dedizierte User (Personen!) sind berechtigt, auf die Software zuzugreifen. Software kann auf einer unbegrenzten Anzahl an Geräten (Client/Server) installiert werden. Jeder authorized user hat Zugriff auf eine unbegrenzte Anzahl an Instanzen der Software, auch gleichzeitig. Ausnahme: Durch den Zusatz Single Install wird die Anzahl möglicher Installationen auf eine einzelne reduziert. Lizenznehmer muss separate, dedizierte Entitlements für jeden User erwerben, der Zugriff auf die Software bekommen soll, egal ob dieser direkt oder indirekt erfolgt (Multiplexing). Die Berechtigung, die aus dem Entitlement erwächst, kann nicht geteilt werden und eine Übertragung auf einen anderen User ist nur über einen permanenten Transfer möglich. Sonderfall: Authorized devices anstatt authorized user Jedes Device benötigt eine User-Lizenz auch wenn das Device nur ein Set an Befehlen, Prozeduren oder Applikationen von der Software zur Verfügung gestellt bekommt.

15 Lizenzmetriken im PPA-Umfeld User-basierte Lizenzierung Floating / Concurrent User Mehrere Nutzer teilen sich eine Lizenz durch zeitlich versetzte Nutzung. Lizenziert werden muss die maximale Anzahl an Nutzern, die die Software gleichzeitig nutzen. Prinzipiell ist eine unbegrenzte Anzahl an Installationen erlaubt. Ausnahme: Durch den Zusatz Single Install wird die Anzahl möglicher Installationen auf eine einzelne reduziert.

16 Lizenzmetriken im PPA-Umfeld User Value Unit Lizenzierung User Value Unit (UVU) Die Lizenzmetrik realisiert einen stufenweise steigenden Discount auf Produktebene. Je größer das Nutzungsvolumen, desto kleiner ist die Zahl an UVU, welche pro User lizenziert werden muss. Rabattstufen sind nicht einheitlich, sondern produktabhängig. Preis wird durch Multiplikation der User Value Units mit dem Listpreis ermittelt Mischlizenzierung ist erlaubt User Value Units kamen mit der FileNet Akquisition 2006 zu IBM Software User Value Unit Lizenzform beispielsweise bei IBM Content Management und IBM FileNet Produkten

17 Lizenzmetriken im PPA-Umfeld User Value Unit Lizenzierung Authorized User Value Unit (AUVU) für selektive Lizenzierung von internen Benutzern oder solchen Benutzern, die im Auftrag des Unternehmens tätig sind (z.b. Contractors und Dienstleister). Employee User Value Unit (EUVU) zur kollektiven Lizenzierung aller Mitarbeiter und Personen, die im Auftrag des Unternehmens tätig sind. External User Value Unit (XUVU) zur Lizenzierung von externen Benutzern, die nicht Mitarbeiter im Unternehmen sind. Regelungen für seltene User sind z.t. auch vorhanden. Proof of Entitlement: SW Produkte können mehrere Lizenzformen haben Mischlizenzierung ist erlaubt

18 Lizenzmetriken im PPA-Umfeld User Value Unit Lizenzierung Kunde möchte 110 User lizenzieren Eine Summe von 93 AUVU ist erforderlich, um die Menge von 110 autorisierten Benutzern zu lizensieren.

19 Lizenzierungstypen Open Systems Lizenzen basierend auf Kapazität Typ Beschreibung Processor Value Units (PVU) Für jeden CPU-Kern, der für die Software relevant ist, werden PVU-Lizenzen benötigt, je nach Typ zwischen 30 (UltraSPARC T1) und 120 (IFLs, große pseries) pro Kern Unter Subcapacity-Bedingungen gelten spezielle Zählregeln Processor Für jeden der Software zugewiesenen Prozessoren wird eine Lizenz benötigt. Dieser Typ wurde durch die PVU-Lizenzen abgelöst normalerweise im Verhältnis 1:100 Install Eine Lizenz berechtigt zur einfachen Installation des Programms auf einem physischen oder virtuellen Datenträger Server Eine Lizenz berechtigt zur Nutzung des Programms auf einem physischen Server (CPU, RAM, I/O), bspw. ein Blade Virtual Server Siehe Server, nur dass hier auch virtuelle Maschinen als eigene Server zählen Millions of Service Units (MSU) Gemäß SCRT-Report werden die Maxima der rollierenden 4-StundenDurchschnittslasten je Software-Produkt gezählt

20 Lizenzmetriken im PPA-Umfeld Installationen Bei der Lizenzmetrik per Install wird per Installation auf einem physikalischen oder virtuellen Medium lizenziert. Achtung: Selbst wenn das Programm nicht genutzt wird, müssen die entsprechenden Lizenzen dafür vorgewiesen werden können. Allein der Fakt, dass das Programm ausgeführt werden könnte, verpflichtet zur Lizenz. Achtung: IBM Software besteht je nach Produkt oft aus vielen Komponenten. Die Installationen mancher Komponenten benötigen eine Lizenz, andere nicht oder nur unter bestimmten Bedingungen. Beispiel: IBM Rational Quality Manager zum Testmanagement wird per User (Authorized oder Floating) Single Install lizenziert

21 Lizenzmetriken im PPA-Umfeld Physikalische Server Ein Server ist ein physikalischer Computer, der aus Verarbeitungseinheiten, Speicher, Ein- und Ausgabefähigkeiten, Kommandos oder Applikationen für einen oder mehrere Nutzer oder Client Devices besteht. Sollten Racks oder andere ähnliche Geräte eingesetzt werden, muss für jedes trennbare physikalische Gerät (z.b. ein Blade oder rack-mounted Device), das Komponenten des Programms enthält, eine Lizenz gehalten werden. Bei der Lizenzierung nach Physical Server muss eine Lizenz für jeden potentiell verfügbaren Server, auf dem das Programm installiert ist und der ready-to-use ist, erworben werden, unabhängig von der Anzahl der Prozessorkerne und/oder Partitionen.

22 Lizenzmetriken im PPA-Umfeld Virtuelle Server Ein Server ist definiert als physikalischer Server. Ein virtueller Server ist entweder ein virtueller Computer, der durch Partitionierung der verfügbaren Ressourcen des physikalischen Servers entstanden ist, oder ein nicht-partitionierter physikalischer Server. Bei einer Lizenzierung nach Virtual Server muss eine Lizenz für jeden potentiell verfügbaren virtuellen Server auf dem das Programm installiert ist und der ready-to-use ist erworben werden; unabhängig von der Anzahl der Prozessorkerne. Beispiele IBM SmartCloud for Application Performance Management IBM DB2 Express Server Edition Limited Use Virtual Server

23 Lizenzmetriken im PPA-Umfeld Prozessorbasierte Lizenzierung Processor Value Units (PVU) Motivation IBM Multiplattform Passport Software vor dem : 1 per Prozessor -Lizenz pro Core mit Ausnahmen z.b. Sparc T1: 0.3 IBM Zitat:... under this licensing approach, one software license was required per processor core. So if a system had 4 processor cores then 4 software license entitlements were needed. With the recent widespread adoption of multi-core chip technologies in today s servers, the per processor licensing approach no longer meets the needs of the underlying processor technologies. Ab dem neue Lizenzmetrik: Processor Value Units (PVU) IBM Middleware wird in Processor Value Units lizenziert, dabei wird jedem Typ Processor Core eine spezifische Anzahl PVUs zugeordnet. Die Processor Value Units sind den PVU-Tabellen zu entnehmen, die ständig um die Prozessoren der neuesten Technologie erweitert werden. Preise pro Processor Value Unit der verschiedenen Middleware-Produkte sind unterschiedlich, so wie bislang der Preis pro Prozessor.

24 Lizenzmetriken im PPA-Umfeld Prozessorbasierte Lizenzierung Im Zuge der PVU-Lizenzierung: IBM definiert: Prozessor als einen Prozessorkern (Core) auf einem Chip (Socket) Achtung: Einige andere Anbieter definieren 1 Prozessor = 1 Chip bzw. 1 Socket Ein Socket ist elektrische Verdrahtung (Platine), die einen Prozessor(-Chip) akzeptiert 1 Prozessor = 1 Thread Ein Thread ist ein paralleler Strang an Instruktionen welche ein Prozessor parallel zu anderen Threads ausführen kann. Manche Prozessorkerne unterstützen Multithreading in Hardware. Ursprünglich war dies eine Funktion des OS(-Kernel) Multi-Core-Prozessoren bzw. -Prozessor-Chips haben mehr als einen Prozessorkern Wie viele Processor Value Units sind pro IBM Software Produkt erforderlich? Ermitteln der Anzahl Processor Value Units pro Core je nach Prozessortyp nach Tabelle (PVU-Faktor) Ermitteln der Anzahl der physikalisch vorhandenen Cores (nicht Threads) eines Systems Anzahl Cores multipliziert mit dem PVU-Faktor, ergibt den Lizenzbedarf eines Systems Summe über alle Systeme mit dem IBM Software Produkt ergibt den Lizenzbedarf für die Software.

25 Lizenzierungstypen Open Systems Exkurs: PVU-Lizenzierung unter SubcapacityBedingungen Um die benötigte Anzahl von PVU-Lizenzen für ein Programm zu bestimmen, geht man wie folgt vor: 1. Für jede LPAR/ VM, wo die betroffene Software installiert ist, zählt man die Anzahl der Prozessorkerne (unter AIX: capped LPARs: EC, uncapped LPARs: VP, regulated WPARs: % * Kapazität der MutterLPAR) 2. Für jeden physischen Server werden diese Zahlen summiert. Ist das Ergebnis keine ganze Zahl, so wird es auf die nächste ganze Zahl aufgerundet 3. Ist die Summe größer als die Zahl der Kerne des Servers, so rechnet man mit der Anzahl der Kerne des Servers weiter 4. Diese multipliziert man mit dem PVU-Wert pro Kern des zugrunde liegenden Serversystems (Tabelle: siehe Link hinten) 5. Zum Schluss summiert man über alle Server und erhält die Anzahl der benötigten PVU-Lizenzen

26 Lizenzierungstypen Open Systems Lizenzierung unter x86 Server mit 8 Kernen1) VM 1 VM 2 VM 3 MQ WAS MQ MQ WAS 4 Cores 4 Cores 1 Core 9 virtual Cores 8 physical Cores Für MQ müssen PVU-Lizenzen für 8 Kerne erworben werden: Je 4 Kerne für VM 1 und VM 2 1 Kern für VM 2 Summe größer als Anzahl physischer Kerne, daher Reduktion auf 8 Kerne 1) Es zählen die physischen Kerne, daher spielt HyperThreading hier keine Rolle Für WAS müssen PVU-Lizenzen für 5 Kerne erworben werden: 4 Kerne für VM 1 1 Kern für VM 3

27 Lizenzierungstypen Open Systems Lizenzierung unter AIX im virtualisierten Umfeld (1/2) Server mit 12 Kernen A B D (capped) E (uncapped) DB2 WAS VP=6 EC=4,00 VP=7 EC=5,00 C Shared pool DB Für DB2 müssen PVU-Lizenzen für 5 Kerne erworben werden: 1 Kern für die dedicated LPAR B 4 Kerne für LPAR D (capped, daher wird der EC-Wert gezählt) Für WAS müssen PVU-Lizenzen für 7 Kerne erworben werden: 7 Kerne für LPAR E (uncapped, daher wird der VP-Wert gezählt) Bei 120 PVU pro Kern sind das 600 PVU für DB2 und 840 PVU für WAS 9

28 Lizenzierungstypen Open Systems Lizenzierung unter AIX im virtualisierten Umfeld (2/2) Server mit 12 Kernen D (c) VP=1 EC=1,00 A B E (c) F (c) G (uc) H (uc) WAS DB2 VP=4 EC=2,00 WAS DB2 VP=4 EC=2,00 WAS DB2 VP=3 EC=1,00 C VP=7 EC=3,00 Shared pool DB Für DB2 müssen PVU-Lizenzen für 8 Kerne erworben werden: 1 Kern für die dedicated LPAR B 7 Kerne für den Shared Pool: Je 2 Kerne für LPARs E und F (capped) 3 Kerne für LPAR H (uncapped) Für WAS müssen PVU-Lizenzen für 9 Kerne erworben werden: 9 Kerne für den Shared pool: 2 Kerne für LPAR F (capped) 10 Kerne für LPARs G und H (uncapped) Summe größer als Anzahl CPUs im Pool, daher Reduktion auf Poolgröße

29 Lizenzmetriken im PPA-Umfeld Processor Value Units (PVU)-Tabellen (1/5): x86 Quelle: Stand: Februar 2014

30 Lizenzmetriken im PPA-Umfeld Processor Value Units (PVU)-Tabellen (2/5): POWER Abhängig v. OS!! Ältere POWER-Modelle in der Original-Tabelle ausgelassen Quelle: Stand: Januar 2014

31 Lizenzmetriken im PPA-Umfeld Processor Value Units (PVU)-Tabellen (3/5): System z Quelle: Stand: Januar ) Each Integrated Facility for Linux (IFL) or Central Processor (CP) engine is equivalent to 1 core. (*) 2) Refers to System z9, eserver zseries, or System/390 servers. 5) z196 refers to IBM zenterprise 196, zec12 refers to IBM zenterprise EC12. 6) z114 refers to IBM zenterprise 114. Zu 1 (*) Cores eines IBM System z werden von IBM per SW als Central Processor (CP) [darf alle Funktionen übernehmen, d.h. z/os, z/linux,...], als IFL [darf nur z/linux und ggf. z/vm betreiben], als ZAAP/ZIIP [darf je nach Modell nur Java & XML oder nur DB2/Data Warehouse und XML Workloads bearbeiten],... konfiguriert. Typen an Cores siehe z.b. IBM Redbook IBM zenterprise EC12 Technical Guide Seiten 93ff. Download des Redbook

32 Lizenzmetriken im PPA-Umfeld Processor Value Units (PVU)-Tabellen (4/5):SPARC etc. Ältere Modelle von UltraSPARC und Single Core aus Original-Tabelle ausgelassen Quelle: Stand: Januar 2014

33 Lizenzierungstypen Open Systems Lizenzierung unter Solaris (1/2) Konfigurationsbeispiel Dynamic System Domains mit UltraSPARC III & IV Prozessor1) Server mit 16 Prozessor Kernen Domain 1 Domain 2 DB2 DB2 1) 8 CPU DB2 cores 4 CPU MQ cores 4 8 Domain 3 MQ 4 CPU Lizenzbedarf 4 CPUs1) Partition 4 Domain 1 8 Domain 2 4 Domain Total all Domains Capacity Limit CPU in 3 Domains CPUs1) (Threads) im Server 16 Server mit 16 Prozessor Kernen 1 CPU (Thread) pro Prozessor Kern # CPUs geteilt durch Threads pro CPU = # Kerne Total Cores Lizenzregel: Das Minimum aus der Summe von jeder Partition für jedes Produkt und der Gesamtkapazität des Servers muss lizenziert werden!

34 Lizenzierungstypen Open Systems Lizenzierung unter Solaris (2/2) Konfigurationsbeispiel Lizenzbedarf Dynamic System Domains mit SPARC64-VI Prozessor1) WAS cores CPUs1) Partition 8 16 Container B Container C Total Resource Pool Capacity Limit Pool 1 8 DB2 cores Server mit 16 Prozessor Kernen A Global Container B Container C Container D Dedicated Container Solaris Solaris Solaris Solaris WAS WAS 8 DB CPU 16 CPU 16 CPU 8 CPU 12 Resource Pool Domain 1 Total Cores 56 CPUs in 4 Containers DB2 Domain 1 8 CPU 16 CPUs (8 Cores) Resource Pool 1 (Default Pool) Domain 2 = 24 CPUs 16 1) 8 CPUs Resource Pool 2 24 CPUs in 2 Resource Pools 32 CPUs1) (Threads) in 2 Domains Server mit 16 Prozessor Kernen 2 CPU (Threads) pro Prozessor Kern # CPUs geteilt durch Threads pro CPU = # Kerne Lizenzregel: Das Minimum aus der Summe von jeder Partition für jedes Produkt und der Prozessorkapazität des Resource Pools

35 Lizenzierungstypen Open Systems Lizenzen basierend auf den verwalteten Systemen Typ Beschreibung Client Device Bei diesem Lizenzmodell muss eine Lizenz für jedes Endgerät erworben werden, das mit der Software genutzt wird, bspw. Laptops, Geldautomaten etc. Resource Value Unit Diese Lizenz bezieht sich auf die Kapazität, die ein Programm nutzt oder verwaltet. Dabei handelt es sich um Programm-spezifische Metriken (bspw. verwaltete Prozessor-Kerne für Tivoli Monitoring); Wie für alle Value Units ist ein Mengenrabatt eingebaut Managed Processor In diesem Modell werden die verwalteten Prozessoren gezählt, es wurde abgelöst durch die Resource Value Units Terabyte Dieses Lizenzmodell ist v.a. für Tivoli Storage Manager im Einsatz und misst das zu sichernde Datenvolumen

36 Lizenzmetriken im PPA-Umfeld Terabyte, Archive-Terabyte Lizenziert wird nach dem Datenvolumen in Terabyte, welches (vom Server) gemanaged wird. Beispiele: IBM Tivoli Storage Manager Unified Recovery Solution (TSM) für Backup/Restore, Archivierung, Hierarchisches Storage Management,... Beliebig viele Komponenten des Programms dürfen installiert werden Maßgeblich sind Terabyte im Primary Storage Pool der TSM-Server Archive Terabyte (erheblich günstiger) Terabyte tiers: (1-100), ( ), ( ), ( ), (751-1,250), (1,251-2,000), (2,001+) Terabyte = 2^40, d.h. 1024*1024*1024*1024 Bytes Klassische / Alternative Lizenzmetrik für TSM-Produkte sind PVU IBM SAN Volume Controller (SVC) alternativ als HW Appliance oder als PA Software Terabyte die verwaltet werden Das TSM & SVC TB-Modell ist ein mehrstufiges Preismodell (tiered pricing): Der Preis pro weiterem TeraByte fällt sukzessive, stufenweise mit dem Datenvolumen.Basis -Tiers unter dem höchsten genutztem sind alle mit zu lizenzieren und mit zu warten.

37 Lizenzmetriken im PPA-Umfeld Resource Value Units Resource Value Units = Eine für ein Programm spezifische Maßeinheit. Typische Größen für die Maßeinheit sind u.a. Cores Terabyte Million Monthly Server Calls (managed by IBM Unica NetInsight) Limited Records and Active Customer Records (managed by IBM Unica CustomerInsight) RVUs sind abhängig von den Ressourcen, die gemanaged werden. Man unterscheidet zwischen managing und managed Ressourcen managing resources: von der Software verwendete Ressourcen managed resources: von der Software verwaltete

38 Lizenzmetriken im PPA-Umfeld Resource Value Units Ähnlich dem User-Value-Unit Modell kumuliert der Rabatt bei steigender RVU-Zahl Beispiel: Tivoli Endpoint Manager; Verwaltete Systeme 20 One Prozessor, Single Core: 20*1*1 = Two Prozessor, Quad Core: 10*2*4 = 80 Basierend auf 100 verwalteten Cores, müssten 100 RVUs lizenziert werden

39 Lizenzmetriken im PPA-Umfeld Device, Managed Port Client-Device-Lizenzierung Lizenzierung richtet sich nach Anzahl der Client Devices, die vom entsprechenden Softwareprogramm gemanaged werden oder auf welchen die Software installiert ist Beispiele für Client Devices: Desktop Computer, Notebooks, Sensoren, Smart Meter, Kassenterminals etc. Dabei werden unterschiedliche Client-Device-Typen unterschieden: Tape, Disk, Network Adapter, Mobile, Switch und SmartMeter Port-Lizenzierung Ein Port repräsentiert ein Netzwerk-Port Bsp. IBM Interact for Interactive Voice Response (ehemals Unica)

40 Lizenzmetriken im PPA-Umfeld Deployed, Branded Application Bei einer Lizenzierung per deployed App wird nach der Anzahl der Applikationen, die auf Devices (via Server) deployed werden, lizenziert. Beispiel: Per Deployed App-Lizenzierung bei der IBM Plattform Worklight zur Entwicklung mobiler Applikationen Dabei ist eine deployed Application definiert als ein Worklight Studio Projekt, das auf Devices (via Worklight Server und/oder App-Stores) deployed wird. Als Additional Brand Deployment kann diejenige App lizenziert werden, die bereits deployed wurde und im Nachhinein unter einem anderen Namen/Marke nochmal deployed wird.

41 Lizenzmetriken im PPA-Umfeld Token Tokens sind ein produkt-übergreifendes Floating-Lizenz-Modell für Produkte der IBM Marke Rational. Tokens werden für eine bestimmte Zeit gemietet (mind. 1 Jahr). Jedes Produkt zieht bei Benutzung eine definierte Anzahl Tokens aus dem Topf. Beispiele: Rational Team Concert (RTC) = 8 Rational ClearQuest (CQ) = 5 Rational Develloper for System z (RDz) = 9 Rational Application Developer (RAD) = 8... Token Pool Project C Der Token-Topf umfasst eine vertraglich definierte Liste von Rational-Produkten, die sich daraus bedienen dürfen. Vorteil: Maximale Flexibilität durch Abfedern von Nutzungsspitzen im Einzelprodukt.

42 Lizenzierungstypen Host Übersicht über die OTC Lizenzierung Erläuterung Preis Value Unit (VU) Pricing OTC Produkte werden auf Basis von Value Units lizenziert Die notwendige Anzahl an Value Units wird produktspezifisch über einen Referenzwert und eine Umrechnungsfunktion (VUE) ermittelt Der Referenzwert für die meisten OTC Produkte ist die Maschinenkapazität der Hardware auf der das Produkt eingesetzt wird Über die Konvertierung mit der Value Unit Exhibit wird eine Preisdegression erreicht Konvertierung Value Unit Exhibit (VUE) Referenzwert Maschinenkapazität (MSU basiert) Maschinenanzahl (Engine basiert) Sonstige (z.b. Messages)

43 Lizenzierungstypen Host Übersicht der wichtigsten Lizenzmetriken MLC Sysplex Aggregation Sub-Capacity fähig AWLC Advanced Workload License Charges Ja Ja VWLC Variable Workload License Charges Ja Ja FWLC Flat Workload License Charges AEWLC Advanced Entry Workload License Charges EWLC Entry Workload License Charges TWLC Tiered Entry Workload License Charges znalc System z New Application License Charges Ja PSLC Parallel Sysplex License Charges Ja MWLC Midrange Workload License Charges Ja zelc zseries Entry License Charges *) mit Einschränkungen zec12 z196 z10 EC z9 EC z990 z900 x x x x Ja Ja z10 BC z9 BC z890 x x Ja zbc12 z114 x x x x x x x x x x x x x x x x x x x*) x*) x*)

44 Lizenzierungstypen Host Exkurs: SubCapacity für MLC-Software Viele MLC-Produkte sind Subcapacity-fähig. Um in diesem Fall die benötigte MSU-Zahl für ein SoftwareProdukt zu bestimmen, geht man wie folgt vor: 1. Zu jeder Stunde wird für jede LPAR, auf der das Produkt zu dieser Zeit aktiv war, die durchschnittliche Auslastung je Stunde über die vorangehenden 4 Stunden bestimmt (in MSU) 2. Die so gewonnenen Werte werden dann für jede Maschine zu einer Summe je Stunde aufaddiert 3. Für jede Maschine wird dann der maximale Summenwert des Monats genommen; diese Werte werden im SCRT Report je Produkt ausgewiesen 4. In einem Parallel Sysplex ist die Summe der Maxima für alle Maschinen der zu lizenzierende MSU-Wert und liefert die Basis für die Abrechnung (WLP Report) Für Produkte, die Teil einer Produktfamilie sind (z.b. z/os Security Server), werden die MSU Werte des Mutterprodukts (in diesem Fall z/os Base) abgerechnet für alle Maschinen, auf denen das Produkt installiert ist, unabhängig davon, auf welchen LPARs das Produkt läuft.

45 Lizenzierungstypen Host Exkurs: SubCapacity für OTC-Produkte Bei OTC-Software gibt es drei Arten von SubCapacity-Lizenzierung: 1. Execution-based Maßgeblich ist die Nutzung des lizenzierten Produkts selbst Die Zählweise der MSU-Werte entspricht dem MLC-Modell, MSU Zahl wird im SCRT Report aufgeführt Beispielprodukt: Fault Analyzer 2. z/os-based Maßgeblich ist die Nutzung von z/os auf allen betroffenen Maschinen Der z/os-wert wird nach dem MLC-Modell ermittelt Beispielprodukt: Tivoli Omegamon XE for z/os 3. Reference-based Maßgeblich ist hier die Nutzung des zugehörigen Referenz-Produkts im gesamten Parallel Sysplex Der MSU-Wert des Referenz-Produkts wird nach dem MLC-Modell ermittelt Beispielprodukt: DB2 Utilities (Referenz-Produkt: DB2) Die MSU Werte werden anschließend in Value Units umgerechnet. Die Umrechnung hängt vom Produkt ab und ist nicht linear.

46 Lizenzierungstypen Host SubCapacity für Host-Software Ermittlung des 4-Stunden-Durchschnitts Rollierender 4-StundenDurchschnitt MSU :0009:0010:0011:0012:0013:0014:0015:0016:00 Nutzung 4h-Durchschnitt Durch den rollierenden 4-Stunden-Durchschnitt werden kurzzeitige Last-Spitzen ausgeglichen Je größer die Ungleichgewichte in der Nutzung sind, desto höher sind die Lizenzkosten im Vergleich zur Gesamtnutzung (Preis pro MSU) Eine möglichst gleichmäßige Auslastung sollte daher das Ziel sein zur Optimierung der Lizenzkosten

47 Lizenzierungstypen Host SubCapacity für Host-Software Aggregation der LPAR-Werte Im abgebildeten Szenario ist die MSU-Nutzung (rollierender 4-Stunden-Durchschnitt) eines SoftwareProdukts auf zwei LPARs (A und B) auf einer Maschine zu sehen. Außerdem ist die Summe der beiden Nutzungskurven abgebildet. Mit einem Pfeil ist jeweils das Maximum des betreffenden Monats markiert. Es wird für dieses Produkt der höchste Wert der summierten Kurve abgerechnet und nicht die Summe der beiden Lastspitzen!

48 Weitere Lizenzierungsfallen

49 Standby-Konzepte Sind Ihnen die unterschiedlichen Standby-Konzepte und deren Auswirkungen auf die Lizenzierung bewusst? Cold / warm / hot Standby: nur hot muss lizenziert werden Achtung: auch mittels Virtualisierungssoftware kann ein hot Standby geschaffen werden

50 Migrations-Betrieb Steht bei Ihnen ein Release-Wechsel an und ist zur Einführung ein Migrations-Szenario geplant? Beispiel: Wechsel von Domino V8.5 auf V9: beide Versionen werden eine gewisse Zeit parallel genutzt, wobei produktiv nur das alte System läuft und das neue im Testbetrieb Regel: während maximal 90 Tagen pro Jahr dürfen solche Parallel-Betriebe installiert sein gem. der Temporary Additional Use Policy

51 Beispiele aus der Praxis

52 Backup/Recovery Umgebung: 1 Anforderung 4 Lösungen Folgendes Praxisbeispiel zeigt wie komplex und vielfältig die IBM Lizenz-Metriken sind. Aufgabe: Finden Sie die optimale Lizenzierung einer neuen Backup/Recovery Lösung basierend auf IBM Spectrum Protect (ehemals Tivoli Storage Manager TSM) für: 4 Fileserver (je 2 Cores à 70 PVU) Total Kapazität durch benutzte Fileablagen: 50 TB Anforderung: je 3 Sicherungskopien auf Storage-Systemen ablegen Wie sieht Ihre Lösung aus? 1. 8x70 PVU = 560 PVU von Spectrum Protect: Total Listenpreis: Euro 2. 4x1 Server = 4 Server von Spectrum Protect Entry Managed Server: Total Listenpreis: Euro TB Spectrum Protect Suite Entry (Frontend Capacity): Total Listenpreis: Euro TB Spectrum Protect Suite Entry (Backend Capacity): Total Listenpreis: Euro Achtung: Je nach Umgebung sieht die präferierte Lizenzierung ganz anders aus!

53 Netzwerk Monitoring: Sisyphos lässt grüßen Im folgenden Beispiel wird ersichtlich, dass es mitunter recht schwierig ist, richtig lizenziert zu sein bei gewissen Produkten. Aufgabe: Finden Sie die richtige Lizenzierung einer neuen Netzwerk-Monitoring Lösung basierend auf IBM Netcool für: Überwachung von 100 Devices im Netzwerk Dann erfolgt eine Beschaffung von weiteren 10 Geräten, welche überwacht werden sollen Wie sieht Ihre Lösung aus? 1. Lizenzierung nach Resource Value Units gem. Umrechnungstabelle in Announcement Letter: Devices mit Faktor 1.0 = 100 RVU nötig Devices dazu mit Faktor 0.9 = 9 RVUs zusätzlich benötigt Achtung: Lizenzmanagement muss stetig genaueste Kenntnisse darüber besitzen, welche Devices im Netzwerk überwacht werden sollen!

54 Server-Anpassungen führen leicht zu Unterlizenzierung Wie rasch eine Unterlizenzierung unbeabsichtigt passieren kann, zeigt das nachfolgende Beispiel. Aufgabe: Sie sind verantwortlich für die auf WebSphere MQ basierte Application Messaging Plattform: Aktuell sind 10 Server mit je 2 Cores à 70 PVU lizenziert. Ohne Ihr Wissen wird ein Server durch einen stärkeren ersetzt (zb der SAP Server, der neusten Intel Prozessor Generation). Ihre MQ Applikationen laufen wie bisher weiter. Wie sieht Ihre Lösung aus? x 70 PVU von WebSphere MQ: Total 1400 PVU 2. SAP Server würde neu 6 Cores à 120 PVU benötigen Unterlizenzierung von 580 PVU Achtung: ein sauberes Infrastruktur- und Lizenzmanagement muss etabliert sein, um solche schleichenden Unterlizenzierungen zu vermeiden!