Vorbereitung › Versionshinweise › Bekannte Probleme › Wichtige Hinweise

Wichtige Hinweise

1. ALD wird nicht mehr dazu verwendet, Grids zu installieren/aktualisieren und Kataloge und Anwendungen zu importieren. Anstelle von ALD wird Backbone Fabric Controller (BFC) verwendet. BFC ist eine einfach einsetzbare, webbasierte GUI-Anwendung, die verwendet wird, um all Ihre CA AppLogic-Grids innerhalb eines einzelnen Backbone zu erstellen und zu verwalten. In der BFC-Dokumentation finden Sie Informationen zum Herunterladen/Installieren von BFC und dessen Verwendung für die Verwaltung Ihrer CA AppLogic-Grids. Um Kataloge und Anwendungen in Ihr Grid zu importieren (d. h., system_ms, mit CA AppLogic geliefert), kopieren Sie den Katalog bzw. die Anwendung zum Impex-Volume Ihres Grid und verwenden Sie die Befehle "cat import" und "app import" von CA AppLogic.
2. CA AppLogic 3.x unterstützt jetzt neben Xen auch den VMWare-ESX-Hypervisor. Während CA AppLogic 3.x alle Funktionen und Funktionalitäten für beide Hypervisoren verwaltet, gibt es einige wichtige Verwendungsaspekte, die speziell für VMWare ESX gelten, wenn dieses mit CA AppLogic verwendet wird:
   • ESX hat eine striktere Hardwarekompatibilitätsliste im Vergleich zu Xen. Überprüfen Sie, ob Ihre Server auf der ESX-Hardwarekompatibilitätsliste stehen, bevor Sie CA AppLogic 3.x verwenden. Die für Ihr ESX-basiertes Grid ausgewählte Hardware muss hinsichtlich der HCL für ESX, CA AppLogic-Xen (im Abschnitt zur Hardwarevereinbarkeit oben angegeben) und CentOS 5.5 überprüft werden.
   • Stark belastete Grids, die ESX anstelle von Xen verwenden, arbeiten bei einigen Operationen langsamer. Dies wird dadurch verursacht, dass CA AppLogic die ESX-APIs verwendet, um virtuelle Computer auf den einzelnen Servern zu steuern; diese APIs sind auf ESX langsamer im Vergleich zu den Xen-APIs. Die Operationen, bei denen diese Langsamkeit am auffälligsten ist, sind folgende:
     • Starten einer Anwendung – Appliances brauchen möglicherweise 1-2 Minuten länger, um auf stark belasteten Grids zu booten
     • grid info, srv list, srv info – können einige Sekunden oder auf stark belasteten Grids 1-2 Minuten länger dauern
   • ESX hat mehr Speicher-Overhead als Xen. Eine Anwendung, die auf 2 Server auf einem Xen-basierten Grid passt, passt möglicherweise nicht vollständig auf die gleichen 2 Server, wenn diese auf einem ESX-basierten CA AppLogic-Grid ausgeführt werden. Darum wird für ESX-basierte Server empfohlen, mindestens 4-8 GB Speicher vorzusehen.
   • Appliances, die ESX unterstützen:
     • Auf allen Appliances müssen VMware-Tools installiert sein (standardmäßig sind VMware-Tools auf allen Appliances installiert, die mit CA AppLogic 3.x geliefert werden). VMware-Tools werden benötigt, damit die grafische Konsole korrekt und so funktioniert, dass die Appliance rechtzeitig herunterfährt. Wenn VMware-Tools nicht installiert ist, ist die grafische Konsole viel schwerer zu verwenden (Mauszeiger lässt sich schwer steuern), und die Appliance braucht 15 Minuten zum Herunterfahren.
     • Bei der Verwendung von Windows-Appliances muss die Appliance die richtige esx_os_name-Einstellung in der Virtualisierungsoptionszeichenfolge aufweisen, die im Appliance-Deskriptor gespeichert ist. Sie können die Einstellung für Ihre Windows-Appliance aktualisieren. Wenn eine neue Windows-Appliance mithilfe von "iso2class" installiert wird, gibt es einen obligatorischen Befehlszeilenparameter, der verwendet wird, um die richtige esx_os_name-Einstellung für die neue Appliance festzulegen.
     • Um eine Appliance neu zu starten, verwenden Sie entweder "comp restart", oder starten Sie die Anwendung neu. Ein Neustart der Appliance aus der Appliance selbst heraus führt zu einem Appliance-Bootfehler (die Appliance kann dann ihre Konfiguration aus CA AppLogic nicht abrufen).
     • Der volfix-Konfigurationsmodus funktioniert nicht für Appliances, die auf ESX ausgeführt werden. Die Appliance muss konvertiert werden, um den dhcp-Konfigurationsmodus verwenden zu können. Dies sollte sich nur auf ältere Appliances von CA AppLogic 2.1 und ältere Versionen auswirken. Sie können Ihre Appliance konvertieren (So werden Ihre Anwendungen für die Verwendung des neuen Appliance-Kits (APK) aktualisiert, Aktualisieren von Appliances zur Verwendung des DHCP-Konfigurationsmodus), um den DHCP-Konfigurationsmodus zu verwenden. Weitere Informationen zur Konvertierung Ihrer Appliance und zur Verwendung des DHCP-Konfigurationsmodus finden Sie im Abschnitt "Appliance-Kit" im Appliance-Entwicklerhandbuch.
3. CA AppLogic 3.x führt eine rollenbasierte Zugriffssteuerung ein (RBAC). RBAC bietet die Möglichkeit, einem Objekt Berechtigungen (Kontrolle über etwas) zu erteilen (Anwendungsvorlage, Anwendungsinstanz, Katalog oder Grid). Wenn ein neuer Benutzer auf einem Grid erstellt wird, ist für diesen Benutzer standardmäßig der Zugriff auf die Objekte des Grids beschränkt. Beispielsweise hat der Benutzer standardmäßig keine Anmeldeberechtigungen für das Grid. Sie müssen entsprechende Zugriffsrechte (Benutzer- und Gruppenverwaltung, RBAC - Übersicht) für Ihre Benutzer konfigurieren, damit diese auf die Grids zugreifen können.
4. Wenn die Web-API für den Zugriff auf Ihr CA AppLogic-3.x-Grid verwendet wird, muss die Web-API-Anwendung mit einem Benutzer konfiguriert werden, der volle Zugriffsrechte auf das Grid hat (Administratorzugriff).
5. In CA AppLogic 3.x ist die Betriebssystemunterstützung für Appliances nicht so umfangreich, wie bei früheren Versionen von CA AppLogic. In Version 3.x wird Solaris 10 überhaupt nicht unterstützt, und OpenSolaris wird nur für Xen unterstützt. Beachten Sie, dass OpenSolaris und Solaris 10 von Oracle eingestellt und durch Solaris Express und Solaris 11 ersetzt werden.

   Hinweis: Alle Solaris-basierten Appliances mit Ausnahme des Solaris-Filers sind ab CA AppLogic 3.5 entfernt worden. Setzen Sie sich mit CA Support in Verbindung, wenn Sie diese Appliances benötigen.

6. CA AppLogic ist hinsichtlich des BS nicht eindeutig konstruiert und kann mit unterschiedlichen Betriebssystemen verwendet werden. Designbedingt werden alle Volume-Operationen ("create"/"format", "copy", "resize", "file-system check"/"repair" und "manage") innerhalb von CA AppLogic-Anwendungen, so genannten Filers, ausgeführt; sie werden nicht mehr von der CA AppLogic-Grid-Steuerung ausgeführt, wie es noch in den Vorgängerversionen von CA AppLogic der Fall war. Diese neuen Filer-Anwendungen verwenden selbst Ressourcen auf dem Grid, wie jede andere normale CA AppLogic-Anwendung auch. Deswegen muss es genug verfügbare Ressourcen auf Ihrem Grid geben, um eine der Volume-Operationen in CA AppLogic ausführen zu können. Beachten Sie, dass die Filer-Anwendungen nicht für Raw-Volumes oder für Volume-Kopien auf Blockebene verwendet werden.
7. Die Grid-Steuerung nutzt 10 % eines Kerns (sowohl für ESX als auch für Xen-basierte Server).
8. Da alle Volume-Operationen jetzt mithilfe von Filer-Anwendungen ausgeführt werden, sind alle Volume-Operationen langsamer im Vergleich zu früheren Versionen von CA AppLogic, da die Filer-Anwendungen im Rahmen der Volume-Operation gestartet/gestoppt werden müssen. Normalerweise gibt es einen Overhead von ungefähr 20 Sekunden für Linux-basierte Volume-Operationen und von ungefähr 130 Sekunden für Solaris-basierte Volume-Operationen.
9. Für alle Appliances wird eine Ressourcenausnutzung mit voller Netzwerkbandbreite umgesetzt. Eine Appliance kann nicht mehr als ihre konfigurierte Bandbreite für alle Terminals verwenden (die zugewiesene Bandbreite berücksichtigt alle Terminals). Stellen Sie sicher, dass die konfigurierte Bandbreite für Ihre Appliances und Anwendungen den Anforderungen an die Bandbreitennutzung entspricht (sonst kann es zu einer starken Verlangsamung der Netzwerkleistungen in Ihrer Anwendung kommen). Die größtmögliche Bandbreite pro CA AppLogic-Server ist 2 GBit.
10. Für Appliances, über die Netzwerkverkehr geleitet wird, wie z. B. Gateways, Lastenausgleichsmodule und Port-Switches, wird die Bandbreite tatsächlich halbiert. Beispielsweise ist ein Lastenausgleichsmodul, dem 100 M Bandbreite zugewiesen wurden, tatsächlich auf 50 M Bandbreite beschränkt (da der Netzwerkverkehr in die Appliance hinein und wieder aus ihr heraus geleitet wird).
11. Bevor ein Benutzer auf einem neu installierten oder aktualisierten CA AppLogic-Grid auf die CA AppLogic-GUI zugreift, sollte der Benutzer den Cache-Speicher des Browsers bereinigen. Wenn der Cache-Speicher des Browsers nicht leer ist, verhält sich die CA AppLogic-GUI nicht korrekt.
12. Auf die Grid-Shell kann entweder über einen Web-Browser oder mithilfe eines ssh-Clients zugegriffen werden. Zur Erhöhung der Sicherheit werden kennwortbasierte ssh-Anmeldungen nicht unterstützt. Ausgenommen hiervon ist die Grid-Installation.

    Wichtig! Wir empfehlen strengstens, dass Sie die mit der CA AppLogic-GUI bereitgestellte Web-Shell verwenden.

13. Wenn auf das Grid über "ssh" zugegriffen wird, ist der Anmeldungsbenutzername unabhängig vom Benutzernamen für CA AppLogic immer "root". Bei ssh-Anmeldungen sind Benutzer und ihre Rollen eindeutig durch ihre öffentlichen ssh-Schlüssel identifiziert.
14. JavaScript und Pop-up-Fenster müssen im Webbrowser aktiviert werden, damit die webbasierte grafische Benutzeroberfläche (Dashboard, Editor, Dokumentation) verwendet werden kann
15. Benutzer sind verantwortlich für die Verteilung, Zuweisung und Verwendung von extern sichtbaren IP-Adressen für Anwendungen; CA AppLogic kümmert sich um alle internen Netzwerkzuweisungen
16. Während der Backbone Fabric Controller alle Grid-Server und -Steuerungen mit sorgfältig vorkonfigurierten Firewalls einrichtet und unnötigen Netzwerkservice deaktiviert, werden Benutzer und Verwalter aufgefordert, die Sicherheitseinstellungen ihrer Systeme zu überprüfen.
17. Die Netzwerkleistung zwischen Servern auf dem für die Kommunikation zwischen Volumes und Appliances verwendeten privaten Netzwerk wird mit ungefähr 900 MBit/s gemessen. Die TCP-Netzwerkleistung, die zwischen Appliances gemessen wird, die sich auf verschiedenen Servern befinden, beträgt 720-900 MBit/s. Wenn Windows ausgeführt wird, liegt die TCP-Netzwerkleistung über 940 MBit/s, und UDP liegt über 500-700 MBit/s.
18. Ressourcenbeschränkungen zu Appliance-Hardware-Ressourcen werden für unterschiedliche Typen von Ressourcen unterschiedlich angewendet (CPU, Speicher, Bandbreite). CPU ist "nicht unter", Speicher ist "genau so viel" (schließt VM-Overhead ein), Bandbreite ist "genau so viel". CPU-Ressourcen können mithilfe der neuen --cap_cpu-Option auf "genau so viel" gesetzt werden, wenn die Anwendung gestartet wird.
19. Wenn eine Anwendung mit einer angegebenen CPU-Mindestgröße gestartet wird, ist nicht garantiert, dass die Anwendung genau diese angegebene CPU-Größe auch abruft. Wenn eine Anwendung mit "cpu=2" gestartet wird, ist es zum Beispiel möglich, dass die Anwendung, wie beobachtet, 1,97 CPU bekommt, wenn die den einzelnen Komponenten der Anwendung insgesamt zugewiesene CPU addiert wird. Dies liegt an Abrundungsfehlern, die auftreten können, wenn versucht wird, den einzelnen Komponenten CPU zuzuweisen.
20. Wenn der Start einer Anwendung fehlschlägt, können nicht alle auf den Fehler bezogenen Meldungen in der Shell angezeigt werden. Untersuchen Sie das Grid-Protokoll mithilfe des Befehls "list log n=20" nach weiteren Informationen.
21. Grids, in denen eine lineare Skalierbarkeit der Leistung wichtig ist, sollten mithilfe von Servern gebaut werden, die hinsichtlich CPU-Typ/Geschwindigkeit, Speichergröße und Plattenkapazität möglichst gleich sind. CA AppLogic funktioniert auch in Grids richtig, die aus Servern mit unterschiedlichen Hardware-Ressourcen zusammengesetzt sind; allerdings kann auf solchen Grids eine unterlineare Leistung beobachtet werden.
22. Der Neustart einer Grid-Steuerung aufgrund eines VM-Fehlers der Grid-Steuerung ist für den Benutzer nicht einsehbar. Wenn die VM der Grid-Steuerung fehlschlägt und CA AppLogic die VM der Grid-Steuerung neu startet, gibt es keine Sichtbarkeit für den Benutzer, während die Steuerung neu startet. Normalerweise dauert es 1-2 Minuten, bis die Grid-Steuerung allein neu startet. Wenn die Grid-Steuerung mehr als 5 Minuten lang nicht verfügbar ist, wenden Sie sich an CA Support.
23. Die Erstellung eines NTFS03-Volumes führt immer zu einem NTFS08-Volume. NTFS08-Volumes können mit Windows 2003 Server verwendet werden.
24. Der "net_discover"-Befehl für Grid und Server wird auf ESX-basierten Grids/Servern nicht unterstützt.
25. Wenn Sie mit Ihren CA AppLogic-Grids ein SAN verwenden, stellen Sie sicher, dass es mindestens 500 GB freien Speicherplatz für jedes Grid gibt, das das konfigurierte NFS-Share verwendet. Sollte das NFS-Share beispielsweise für fünf unterschiedliche Grids verwendet werden, sollte das Share 2,5 TB freien Festplattenspeicher haben.
26. Wenn Sie mit Ihren CA AppLogic-Grids ein SAN verwenden und das SAN oder das NFS-Share geht für unbestimmte Zeit offline, können einige Volumes, die zu diesem Zeitpunkt verwendet werden, unter Umständen korrumpiert werden. Wenn diese Korruption dazu führt, dass die Grid-Steuerung nicht ausgeführt werden kann oder dass Anwendungen nicht starten können (oder es kommt zu anderer Grid- oder Anwendungsinstabilität), setzen Sie sich sofort mit CA Support in Verbindung.
27. Um CA AppLogic-Appliances zu verwenden, die auf den neuesten Betriebssystemdistributionen (wie Fedora Core, Ubuntu, Debian und CentOS) basieren, konfigurieren Sie den neuen Feldentwicklungscode 128 an der Begrenzung der Appliances. Dieser neue Feldentwicklungscode weist CA AppLogic an, ein neueres Gerätenamensformat für die Appliance-Volumes zu verwenden, die speziell von diesen neueren Distributionen verwendet werden. Wenn der Feldentwicklungscode 128 nicht angegeben wird, können auf diesen neueren Distributionen basierende Appliances nicht gestartet werden.
28. Wenn entweder Ihre Primärdatenbank oder Ihre BFC-Datenbankreplikation verloren geht oder beschädigt wird, können Sie sie möglicherweise aus einer automatischen Sicherung wiederherstellen, die in der 3.1-Version des BFC immer ausgeführt wird. Diese Sicherungen befinden sich eigentlich in einem Unterverzeichnis der primären Datenbank. Sie sind also kein Ersatz für das Konfigurieren eines Replikats. (Diese Sicherungen werden auch in ein Unterverzeichnis des Replikats geschrieben, wenn Sie eins konfiguriert ist.) So führen Sie eine Wiederherstellung der letzten Sicherung aus:
    • Warten Sie 2 Minuten, nachdem alle aktiven Grid-Vorgänge abgeschlossen wurden, um sicherzustellen, dass die Sicherung aktuell ist.
    • Melden Sie sich beim BFC-System als root an.
    • Führen Sie /bin/db_restore aus (standardmäßig ist dies /opt/bfc/bin/db_restore). Das Hilfsprogramm "db_restore" hält das BFC an (wenn es noch ausgeführt wird), führt aus der letzten Sicherung eine Wiederherstellung der Datenbank aus, und startet anschließend den BFC neu.