|
|
|
Dieser Abschnitt beschreibt die derzeit bekannten Probleme und Beschränkungen.
Dies heißt, dass eine Appliance nur mit verbundenen Appliances kommunizieren kann (plus ihrem eigenen Server und der Grid-Steuerung). Trotzdem sollten Protokolle auf neuen Appliances richtig angegeben werden, um die Integrität des Anwendungsdesigns und die Kompatibilität mit künftigen Versionen von CA AppLogic sicherzustellen.
Der insgesamt vom Befehl "grid info" gemeldete verfügbare Festplattenspeicher ist eine grobe Schätzung und berücksichtigt das Spiegeln von Volumes nicht. Der tatsächlich verfügbare Festplattenspeicher ist der gemeldete verfügbare Betrag, geteilt durch die Anzahl der Spiegelkopien (standardmäßig 2 Spiegelkopien). Wenn zum Beispiel dort 1000 GB verfügbarer Festplattenspeicher angegeben ist und das Grid für die Spiegelung von 2 konfiguriert wurde, beträgt der verfügbare Festplattenspeicher 500 GB. Um Volumes erfolgreich zu spiegeln, muss ausreichend Festplattenspeicher auf mindestens X Servern vorhanden sein, wobei X die Anzahl von Spiegelkopien ist (die Erstellung eines Volumes in CA AppLogic schlägt nicht fehl, wenn eine dieser Spiegelkopien nicht erstellt werden kann; stattdessen wird eine Warnung angezeigt, dass das Volume nicht gespiegelt werden konnte).
Wenn eine Anwendung gestartet wird und einer der Server auf dem Grid fehlschlägt, kann die Anwendung nicht gestartet werden, wenn eine oder mehrere der Appliances der Anwendung planungsgemäß auf dem fehlgeschlagenen Server ausgeführt werden sollten. Wenn diese Situation auftritt, starten Sie einfach die Anwendung neu.
Um größere Dateien auf Ihr Volume hochzuladen, verwenden Sie den Shell-Befehl "vol manage"; vergessen Sie dabei nicht, die externen IP-Einstellungen für diesen Befehl anzugeben, damit ein Remote-Zugriff aus dem Volume-Manager heraus möglich ist. Weitere Informationen finden Sie in der Referenz zum Befehl vol manage.
CA AppLogic unterstützt den Start von OpenSolaris-Appliances von einem zfs-basierten Startvolume aus. Beachten Sie allerdings, dass dies nicht durch CA überprüft wurde und möglicherweise nicht funktioniert. Solaris 10 unterstützt "zfs" nicht.
Gegenwärtig ist dies auf zfs-Pools mit Einzelgeräten beschränkt. Um alle zfs-Möglichkeiten in CA AppLogic auch tatsächlich zu nutzen, können Benutzer ihr eigenes zfs-Pool in ihren eigenen Appliances zusammensetzen. Wenn ein zfs-Pool für die Spiegelung verwendet werden soll, muss beim Erstellen der CA AppLogic-Volumes, die im Pool verwendet werden, die CA AppLogic-Spiegelung deaktiviert werden (Option "mirrored=0" beim Erstellen der Volumes). Ein zfs-Pool, das mithilfe des Solaris-Filers in CA AppLogic erstellt wurde, funktioniert ebenfalls nicht in Solaris 10. Alle Beschränkungen in CA AppLogic hinsichtlich des Betriebssystems finden Sie in RefOsLimitations.
Wenn Sie einen größeren Speicher benötigen, verwenden Sie ein unterschiedliches Dateisystem.
Der neue dhcp-Konfigurationsmodus unterstützt die Eigenschaftsmarkierung für die Appliance-Konfiguration nicht. Wenn Appliances vom volfix- zum dhcp-Konfigurationsmodus portiert werden, beschreibt die APK-Dokumentation, wie mit Appliances umgegangen werden soll, die bei der Konfiguration der Appliance von der Eigenschaftsmarkierung abhängen. Weitere Informationen finden Sie in Appliance-Kit (APK).
Um die Validierungs-Flags für eine Anwendung anzuzeigen, öffnen Sie die Anwendung im Bearbeitungsmodus. Die Validierungs-Flags werden verwendet, um Appliances zu kennzeichnen, bei denen nicht alle obligatorischen Eigenschaften/Terminals/Volumes richtig konfiguriert sind.
"iso2class" kann verwendet werden, um eine Solaris-10-Appliance mithilfe der grafischen Konsole für den Installationsprozess zu installieren. Nachdem die Installation abgeschlossen ist und die Appliance wieder gestartet wurde, kann die grafische Konsole immer noch verwendet werden, allerdings nur noch im Textmodus (kein Zugriff auf den Solaris-10-Desktop – streng textbasierter Zugriff). Dies liegt an einem Problem in der GUI von Solaris 10 (kein Fehler in CA AppLogic).
Deswegen kann die grafische Konsole nicht mit diesen Appliances verwendet werden. Dies wird absichtlich gemacht, um die Appliances so kompakt wie möglich zu halten. Mithilfe des neuen iso2class-Hilfsprogramms können Benutzer ihre eigenen Appliances mit voller Desktopunterstützung erstellen.
Dieser Fehler ist darauf zurückzuführen, dass CA AppLogic den Computernamen einer Appliance auf ihren Instanzennamen festlegt. Wenn mehr als 1 Appliance, die auf einem Grid ausgeführt werden, alle den gleichen Instanzennamen haben, wird der Doppelbenennungsfehler in Windows auf der grafischen Konsole angezeigt. Dieser Fehler ist nur eine Warnung und wirkt sich nicht auf das Grid oder seine Funktion aus. Wenn Sie Windows als Domänen-Controller verwenden müssen, müssen Sie allerdings die Computernamen auf eindeutige Namen für die einzelnen Appliances setzen. Sie können das Hilfsprogramm wincfg verwenden, um den Computernamen in Ihrer Appliance festzulegen.
Wir haben mit Java-Version 6, Update 7, auf IE/FF/Chrome/Safari getestet. Wenn nicht die neueste Version von Java verwendet wird, funktioniert die grafische Konsole evtl. nicht richtig (sie bleibt beim Ladeversuch hängen). Bevor Sie Fehler in der grafischen Konsole an CA melden, überprüfen Sie, ob Sie die aktuellste Java-Version verwenden (wenn Sie Java in Ihrem Browser aktualisieren müssen, achten Sie darauf, dass Sie Ihren Browser danach wieder öffnen müssen, damit die grafische Konsole richtig funktioniert).
Wenn ein sekundärer Server als der neue Primärserver übernimmt und nicht genug verfügbare Ressourcen auf dem Server vorhanden sind, um die Grid-Steuerung zu starten, dann startet CA AppLogic die Appliances, die auf dem neuen primären Server ausgeführt werden, auf anderen Servern im Grid neu, damit die Grid-Steuerung auf dem neuen Primärserver gestartet werden kann. Beachten Sie, dass dadurch die Failovergruppen der Appliance aufgebrochen werden können. Wenn CA AppLogic eine dieser Appliances anhält, kann die Appliance möglicherweise nicht auf einem anderen Server neu gestartet werden, weil nicht genügend Ressourcen für den Bedarf der Failover-Gruppe vorhanden sind.
Alle HVM-basierten Appliances (Solaris 10, Windows usw.) verwenden mehr Speicher auf dem Server als für sie in der Konfiguration vorgesehen. Typischerweise verwendet die Appliance in Abhängigkeit vom Speicherplatz, der einer HVM-basierten Appliance zugewiesen wurde, zusätzlichen Speicher auf dem Server, auf dem sie ausgeführt wird. (Dieser zusätzliche Speicher wird von dem Virtualisierungs-Hypervisor benötigt, der auf dem Server ausgeführt wird, und wird Schattenspeicher genannt.) Deswegen ist es möglich, dass die Appliance nicht auf dem Server ausgeführt werden kann, obwohl auf dem Server genug Speicher im Vergleich zu dem der Appliance zugewiesenen Speicher verfügbar ist, da zusätzlicher Schattenspeicher für HVM-basierte Appliances benötigt wird, der dann nicht für den Server verfügbar ist. Der CA AppLogic-Planer berücksichtigt diesen zusätzlichen Schattenspeicher bei der Planung von Appliances während des Anwendungsstarts.
Wenn ein 10G-Backbone verwendet wird, ist der größtmögliche Durchsatz, der zwischen Appliances, die auf verschiedenen Servern ausgeführt werden, erreicht werden kann, 2 GBit/s (möglicherweise aufgrund einiger Beschränkungen innerhalb des von CA AppLogic verwendeten Hypervisors).
Stattdessen kann jeder andere Browser verwendet werden.
Freigegebene Schnittstellen sollten mit allen anderen Betriebssystemen funktionieren.
Folgende Probleme sind für diese Version bekannt:
Wenn HP Smart Array RAID Controller ohne Schreibcache verwendet wird, reduziert sich die Leistung um 50 %. Dieses Problem wurde auf einem HP DL 580 G7-Server mit SMART Array P410i 256mb überprüft. Diese Karten erfordern, dass eine Batterie oder ein Kondensator installiert werden, um das Schreibcache zu aktivieren.
Wenn Sie ServerEngines Corp. Emulex OneConnect 10Gb NIC (be3) (rev 01) NICs mit CA AppLogic verwenden, stoßen diese NICs die Pakete falsch ab, wenn die SR-IOV BIOS-Option aktiviert ist. Diese abgestoßenen Pakete verändern das Weiterleitungs-Cache der Bridge, was dazu führt, dass die Bridge Pakete fallen lässt, anstatt sie zum richtigen Ziel zu befördern. Dies verursacht Instabilität in CA AppLogic, was in periodischen Startfehlern der Anwendung resultiert. Stellen Sie deswegen sicher, dass die SR-IOV BIOS-Einstellung für alle Emulex 10G-NICs auf allen Servern innerhalb des Grid DEAKTIVIERT ist.
Wenn ein 10G-Backbone verwendet wird, ist der größtmögliche Durchsatz, der zwischen auf verschiedenen Servern ausgeführten Appliances erreicht werden kann, ungefähr 2,5 Gbps (Sie sehen möglicherweise unterschiedliche Ergebnisse je nach dem Typ der 10G-Hardware, die verwendet wird). CA erforscht gegenwärtig verschiedene Netzwerkoptimierungen (wie das Aktivieren von Jumbo-Rahmen), die in künftigen CA AppLogic-Versionen aktiviert werden können, um die 10G-Netzwerkleistung zu verbessern.
Sehr selten kann eine Anwendung aufgrund einer stecken gebliebenen Volume-Bereitstellung auf einem der Server nicht gestartet werden. CA AppLogic erkennt stecken gebliebene Volume-Bereitstellungen und meldet diese über das Grid-Dashboard an den Benutzer. Wenn dieses Problem auf Ihrem Grid auftritt, benachrichtigen Sie den CA Support. Optional kann das Problem auch durch Deaktivieren des Servers oder einen Neustart des Servers mit den stecken gebliebenen Bereitstellungen gelöst werden.
Wenn diese Situation auftritt, wird durch einen Neustart des Primärservers das Grid in einem Betriebsstatus neu hergestellt.
VDS: Sicherheitsanfälligkeit: Setup des ersten Benutzers/des ersten Kennworts
Wenn auf die CA AppLogic-GUI mithilfe von Microsoft Internet Explorer 6 oder 7 zugegriffen wird, zieht die GUI Speicher, wenn Anwendungen zur Bearbeitung geöffnet werden oder wenn die Webshell geöffnet wird (5-20 MB des Systemspeichers werden für jede dieser Operationen abgezogen). Es wird empfohlen, alle paar Stunden den Browser zu schließen und wieder zu öffnen, um den abgezogenen Speicher wiederherzustellen. Anstelle von Internet Explorer können auch Firefox, Chrome oder Safari verwendet werden.
Die GUI meldet den Benutzer nicht mehr automatisch ab, wenn es eine hohe Last auf der Grid-Steuerung gibt. Stattdessen erhält der Benutzer eine Meldung mit der Information, dass ein Netzwerkfehler aufgetreten ist. In diesem Fall ist die GUI allerdings noch vollständig funktional. Die Netzwerkfehlermeldung wird nur empfangen, wenn es eine hohe Last auf der Steuerung gibt, wie beispielsweise 4 gleichzeitig startende Anwendungen UND das Kopieren eines großen Volumes mit vielen GB. Versuchen Sie in großen Grids, der Steuerung bis zu einem vollständigen CPU-Kern und 1 GB RAM zuzuweisen.
Wenn ein Grid mithilfe des Befehls "grid reboot" neu gestartet wird, können eines oder mehrere Systemvolumes heruntergestuft werden, wenn das Grid nach dem Neustart zurückkommt. CA AppLogic repariert diese Volumes automatisch mit der höchsten Priorität.
Stellen Sie beim Migrieren eines Volumes sicher, dass sich mindestens einer seiner Streams auf einem aktivierten Server befindet, da sonst der Migrationsbefehl fehlschlägt. Das Volume kann bei der Migration vollkommen aus seiner ursprünglichen Menge von Servern herausbewegt werden, indem das Volume zweimal migriert wird.
Einige physische Server brauchen eine lange Zeit, um zu starten - dies kann dazu führen, dass die automatische Grid-Wiederherstellung in CA AppLogic fehlschlägt. Das hat zur Folge, dass möglicherweise nicht alle Anwendungen automatisch neu gestartet werden können, nachdem das Grid nach einem Fehler wiederhergestellt wird. Dies liegt daran, dass die Grid-Steuerung maximal 10 Minuten darauf wartet, dass alle Server neu starten und sich mit der Grid-Steuerung verbinden (was möglicherweise nicht genug Zeit ist, dass alle Server neu starten können). Eine Problemumgehung besteht darin, Anwendungen manuell neu zu starten, nachdem sich alle Server wieder mit der Grid-Steuerung verbunden haben – führen Sie "list srv" aus, um sicherzustellen, dass alle Server mit der Grid-Steuerung verbunden sind – alle sollten einen aktiven Status (UP) aufweisen. In CA AppLogic 2.1 mit einer Zeitüberschreitung von 10 Minuten beim Starten des Servers kann dies hauptsächlich auftreten, wenn ein Server aufgrund eines Hardwarefehlers oder einer BIOS-Fehlfunktion nicht starten kann.
Wenn der Operator das Grid neu startet, wird davon ausgegangen, dass der Flapping-Status zurückgesetzt wird, und auf dem Dashboard sollte eine Meldung mit der Information angezeigt werden, dass der Operator das Grid absichtlich neu gestartet hat ("Grid wurde durch den Operator neu gestartet..."). Gelegentlich wird die Grid-Datei beim Neustart des Grids weder zurückgesetzt, noch wird die Dashboard-Meldung angezeigt. Das einzige Problem, das dies verursachen kann, ist, dass die Anwendungen beim nächsten Grid-Fehler möglicherweise nicht automatisch neu gestartet werden (je nachdem, wie oft das Grid ausgefallen ist, wenn dieser Fehler auftritt). Um dieses Problem, dass nach einem absichtlichen Grid-Neustart keine Dashboard-Meldung angezeigt wird, zu umgehen, wenden Sie sich an den CA Support, um den Flapping-Status des Grid zurücksetzen zu lassen.
Der Grund für die leicht reduzierten Ressourcen hat mit der Zuweisung von Dienstbereichen zu tun. Für Speicher liegt dies wahrscheinlich an der Beziehung von XEN zur Speicherzuordnungstabelle für eine virtuelle Maschine. Für Festplatten liegt dies an den normalen Dienstbereichen des Dateisystems (dies ist das gleiche wie bei normalen Linux-Servern).
In diesem Fall wird die Anwendung nicht durch einen anderen Benutzer zum Bearbeiten geöffnet, aber der CA AppLogic-Editor geht irrtümlicherweise davon aus, dass jemand anderes die Anwendung zum Bearbeiten geöffnet hat. Wenn dies auftritt, überschreiben Sie einfach die Anwendungssperre, wenn Sie beim Öffnen der Anwendung vom Editor diesbezüglich gefragt werden.
Die Verlangsamung tritt hauptsächlich auf, wenn eine Anwendung im CA AppLogic-Anwendungseditor geöffnet wird.
Wenn auf dem Client die grafische Konsole geöffnet ist und die Internet-Verbindung verloren geht (Fehler der Client-Netzwerkkarte, Absturz des Client-Computers, Internet-Zugriff ist nicht verfügbar usw.), dauert es 15 Minuten, bis die grafische Konsole wieder geöffnet wird.
Die Maus lässt sich in Ubuntu nur schwer verwenden, wenn die grafische CA AppLogic-Konsole verwendet wird. Dies liegt an einer Beschränkung bei der XEN-VNC-Unterstützung (Mausbeschleunigung wird nicht unterstützt). Einige Benutzer melden, dass das Problem gelöst werden kann, wenn die Mauseinstellungen in Ubuntu angepasst werden. Auch kommt es in seltenen Fällen dazu, dass Text bei der Eingabe über die Tastatur mehrfach wiederholt wird. (Löschen Sie in solchen Fällen einfach die zusätzlichen Zeichen, die angezeigt werden).
Dies schließt Kennwörter ein, die für die Anmeldung bei der Appliance verwendet werden. Die Textstartkonsole sollte nur für Debugging-Zwecke verwendet werden. Für alle anderen Zwecke kann stattdessen die SSH-Konsole verwendet werden.
Wenn ein Benutzer die Textstartkonsole für eine Appliance erneut öffnet, nachdem sie bereits geöffnet wurde, muss die Eingabetaste gedrückt werden, um entweder die Anmeldeaufforderung oder die Eingabeaufforderung zu sehen. Dies liegt daran, dass die Startkonsole auf eine Benutzereingabe wartet (entweder auf Anmeldeinformationen oder einen auszuführenden Befehl).
Wenn ein Grid eine Appliance hat, die Teil einer Failovergruppe ist, die auf einem sekundären Server ausgeführt wird, wo die Grid-Steuerung neu gestartet werden muss, kann CA AppLogic diese Appliance anhalten, wodurch die Failovergruppe aufgebrochen wird.
Nachdem ein Grid auf die letzte Version aktualisiert wurde, wird eine Dashboard-Meldung mit der Information ausgegeben, dass auf dem Grid aufgrund eines Hardwareproblems ein Fehler aufgetreten ist. Diese Meldung kann ohne Probleme ignoriert und aus dem Dashboard entfernt werden.
Das Appliance-Kit (APK) funktioniert momentan aufgrund einiger Inkompatibilitäten mit dem neueren BS nicht mit Ubuntu 9.10 oder 10.x. Allerdings gibt es verschiedene Beiträge auf den CA AppLogic-Foren, die beschreiben, wie einige der späteren BS-Distributionen mit CA AppLogic verwendet werden können.
Wenn eine Netzwerk-HA-Konfiguration mit CA AppLogic verwendet wird, und ein externer Netzwerkfehler vorliegt, können Anwendungen/Appliances, die externe Schnittstellen verwenden, für bis zu 5 Minuten unerreichbar sein. Dies scheint von dem externen Router verursacht zu werden, der die MAC-Adressen zwischenspeichert. Der Betrieb wird wieder aufgenommen, nachdem der ARP-Zwischenspeicher des Routers geleert wurde bzw. von der Anwendung eine ARP-Antwort mit Arping gesendet wurde. Davon ist nur das externe Netzwerk (nicht das Backbone-Netzwerk) betroffen.
Solaris 10 funktioniert mit CA AppLogic 3.x weder auf Xen- noch auf ESX-Servern.
OpenSolaris funktioniert nur auf XEN-basierten Servern.
Die Wiederherstellungs-GUI funktioniert nur auf XEN-basierten Servern.
Gemeinsam genutzte Schnittstellen unterstützen keine Appliance-Zähler.
Wenn ein Benutzer das Grid aus- und wieder einschaltet, wird die Systembetriebszeit nicht zurückgesetzt. Wenn das Grid neu gestartet wird, sollte die Systembetriebszeit zurückgesetzt werden.
Wenn ein Benutzer ein Grid aus- und erneut einschaltet, und dabei den power_cycle-Befehl verwendet, schlägt der Primärserver möglicherweise dabei fehl, neu zu starten. Dies tritt nur auf, wenn der Befehl nach der Installation eines neuen Grids ausgeführt wird und das Grid nie neu gestartet wurde, bevor der Befehl zum Ein- und Ausschalten des Servers ausgeführt wurde. Ein Grid zu einem Zeitpunkt nach der Installation eines neuen Grids neu zu starten, wird dieses Problem vermeiden.
Wenn die Größe des NFS-Shares bei der Grid-Ausführung geändert wird, wird dies von CA AppLogic erst erkannt, nachdem das Grid neu gestartet wurde. Dieses Problem wird in einer künftigen Version behoben.
Wenn ein Grid, das ein SAN verwendet, gelöscht wird, löscht CA AppLogic den Inhalt des Grid-Ordners, hinterlässt jedoch einen leeren Ordner. Dieses Problem wird in einer künftigen Version behoben.
Dell-basierte Server, die H200-RAID-Karten verwenden, können nicht mit CA AppLogic verwendet werden. Dieses Problem wird in einer künftigen Version behoben.
Die Umgehungslösung für dieses Problem besteht darin, Hardware-RAID auf dem Dell-Server zu aktivieren, bevor er für die Grid-Erstellung verwendet wird.
RedHat 5.3-basierte Appliances können mithilfe von iso2class nicht installiert werden. Dieses Problem wird in einer künftigen Version behoben.
Es kann in seltenen Fällen vorkommen, dass das Upgrade auf 3.5 von 3.0 oder 3.1 fehlschlagen kann. Bei diesem speziellen Upgrade-Fehler sind die folgenden Meldungen im Statusprotokoll des Grid enthalten, auf das mithilfe des BFC zugegriffen werden kann (klicken Sie auf den Status des Grid, um das Protokoll zu öffnen).
installing the controller image ioctl: LOOP_SET_FD: Device or resource busy installing new controller FAILED, aborting
Wenn diese Meldungen im Protokoll vorhanden sind, führen Sie das Upgrade erneut durch. Diesmal sollte es erfolgreich sein.
Hinweis: Dieses Problem kommt sowohl in CA AppLogic 3.0 als auch in 3.1 vor und wird in CA AppLogic 3.5 behoben.
Für ein ESX-basiertes Grid funktioniert der Rollbackbefehl von 3.5 auf 3.1 nicht. Allerdings kann als Workaround der Downgrade-Befehl verwendet werden (bedenken Sie jedoch, dass ein Downgrade länger dauert als ein Rollback). Dieses Problem wird in einer künftigen Version behoben.
Ext3-snapshot-basierte Volumes funktionieren nicht auf ESX-basierten Grids. Allerdings funktionieren diese Volumes auf XEN-basierten Grids. Wenn Sie ein ESX-basiertes Grid verwenden und ein ext3-snapshot-Volume einsetzen müssen, können Sie Ihrem Grid einen XEN-basierten Knoten hinzufügen und Ihre ext3-snapshot-Volumes anhand dieses Knotens erstellen/verwalten (deaktivieren Sie bei Ausführung der Volume-Befehle alle ESX-Server, sodass der CA AppLogic-Filer auf dem XEN-basierten Knoten läuft). Dieses Problem wird in einer künftigen Version behoben.
Der Versuch, einen Volume-Stream im lokalen SAN zu migrieren, schlägt unter Umständen in Grids fehl, die für die Verwendung eines externen SAN konfiguriert sind. Statt den Volume-Stream in das lokale SAN zu migrieren, versucht CA AppLogic fälschlicherweise, den Stream in das externe SAN zu migrieren. Wenn dieser Fehler auftritt, verwenden Sie die Option store=local in Verbindung mit dem Befehl vol migrate. Dieses Problem wird in einer künftigen Version behoben.
Wenn CA AppLogic vom 3.0.30 auf 3.5.x aktualisiert wird, bleibt die Grid-Steuerung vorübergehend hängen, und bei der Ausführung jedes 3tshell-Befehls wird eine Fehlermeldung zu niedriger Speicherkapazität zurückgegeben.
Um das Problem zu umgehen, starten Sie die Grid-Steuerung neu. Dieses Problem wird in einer künftigen Version behoben.
Bei einigen Broadcom-NICs, insbesondere bei der NetXtreme II BCM5709/5716, werden 100 Mbit/s oder 10 Mbit/s vom NIC-Treiber als Verbindungsgeschwindigkeit gemeldet. Dadurch schlägt die CA AppLogic-Installation fehl.
Um das Problem zu umgehen, versuchen Sie eine Neuinstallation. Dieses Problem wird in einer künftigen Version behoben.
Die auf der Grid-Steuerung installierte OpenSSH-Version beschränkt die Anzahl gleichzeitiger SSH-Sitzungen im Multiplexmodus auf 10. Wenn mehr als 10 asynchrone Anforderungen ausgeführt werden, werden sie von der API verworfen.
Um das Problem zu umgehen, geben Sie weniger als 10 gleichzeitige asynchrone Anforderungen an die API aus. Dieses Problem wird in einer künftigen Version behoben werden.
Wenn Sie eine Assembly- oder Komponentenschnittstelle umbenennen, wird der Anwendungseditor nicht vollständig geladen. Dieses Problem wird in einer künftigen Version behoben werden.
Auf Servern mit diesen NICs gibt nach der Erstellung eines Grid die Ausgabe von srv info srvX –extended den Status der NICs als aktiv-außer Betrieb an. Dies wurde als Hardware-spezifisches Problem identifiziert. Um das Problem zu umgehen, melden Sie sich bei dem jeweiligen Switch an, schließen den Port der NIC auf dem srvX und aktivieren ihn erneut. Als Status sollte jetzt "in Betrieb" angezeigt werden. Dieses Problem wird in einer künftigen Version behoben.
Es wurde beobachtet, dass auf Dell PE R710-Servern mit Broadcom NetXtreme II 57711 (bnx2x) 10GbE-NICs der BFC die Server nicht erkennt, wodurch die Installation fehlschlägt. Dabei handelt es sich um ein Hardware-spezifisches Problem, das in einer zukünftigen Version behoben wird.
Die folgenden Probleme sind die wichtigsten bekannten Probleme mit Windows-Appliances in dieser Version. Weitere Prozeduren und Hinweise finden Sie in der Installationsreferenz für die Windows-Appliance.
Bei Verwendung des neuen Windows-APK, der mit CA AppLogic 3.5 kommt, kann es vorkommen, dass die Windows 2003 Server 64-bit Data Center-Ausgabe zwischenzeitlich nicht startet, wenn sie in einem Xen-basierten Grid eingesetzt wird. Wenn es zu diesem Problem kommt, kann der Neustart der Appliance dieses beheben. Dieses Problem wird in einer künftigen Version behoben.
Der Windows Filer kann eine Volume-Größenänderungsoperation nicht ausführen, wenn das Quell-Volume einen beschädigten Verzeichniseintrag/eine beschädigte Datei enthält. Die Hauptquelle dieses Problems kommt von der Tatsache, dass einige Microsoft-Softwareinstallationen absichtlich ungültige Verzeichniseinträge enthalten. (Wir sind nicht sicher, warum dies so ist; es wurde aber beobachtet, als ein Benutzer eine Microsoft SQL Server-Version in seiner Appliance installierte.) Außerdem kann das Quell-Volume aufgrund normaler Abnutzung beschädigt sein. Dieses Problem kann umgangen werden, indem eine Dateisystemreparatur auf dem Volume ausgeführt wird ("vol fsrepair"), bevor die Größe des Volumes geändert wird.
Es wurde von CA beobachtet, dass die Größenänderungsoperation für NTFS-Volumes ungefähr in 2 von 100 Fällen fehlschlägt. Diese 2 Fehler sind aufgetreten, weil der Windows Filer nicht korrekt auf dem Grid starten konnte. Wenn dieses Problem beobachtet wird, sollte eine zweite Wiederholung der Größenänderungsoperation ausreichend sein. Dieses Problem sollte allerdings in dieser Version gelöst werden; wenn Sie dieses Problem beobachten, benachrichtigen Sie den technischen Support von CA.
Der Windows Filer verwendet ein Microsoft-Hilfsprogramm mit dem Namen "diskpart", um die Windows-NTFS-Volumes zu behandeln. Ab und zu kann "diskpart" keine Volume-Informationen abrufen oder das Volume nicht bereitstellen. Dies ist ein sehr seltener Fehler und kann dazu führen, dass "vol create" oder "vol resize" auf NTFS-Volumes fehlschlagen.
Wenn der Benutzer eine Anwendung hat, die eine Windows-Appliance enthält, und der Anwendung oder den Terminals eine oder mehrere Windows-Appliances hinzugefügt werden/aus den Windows-Appliances entfernt werden, erkennen einige der Windows-Appliances beim ersten Start der Anwendung möglicherweise doppelte IPs auf ihrem internen Netzwerk (dies kann nur beim ersten Start einer Anwendung nach einer Änderung geschehen). Dies sollte weder einen Betriebsausfall der Anwendung verursachen noch ein Eingreifen durch den Benutzer erforderlich machen; die doppelten IP-Adressen sind ausschließlich temporär. Schlimmer ist es, wenn ein Teil der Netzwerkkommunikation, der eine der Windows-Appliances betrifft, für bis zu 30-60 Sekunden verzögert wird.
Ein Versuch, eine Windows-Anwendung anzuhalten, ist bei 99 % hängen geblieben; nach 15 Minuten hat die Operation eine Zeitüberschreitung ausgelöst. Die Anwendung enthielt 2 Instanzen einer Windows-2003-Server-DataCenter-Edition-Appliance (WIN03DC). Bei der Ausführung von "comp stop" hat eine der Windows-Appliances angehalten, und die andere ist hängen geblieben. Dies wurde nur einmal beobachtet und konnte nicht reproduziert werden.
Ab und zu werden Nullen für die folgenden Festplatten-E/A-Zähler für Windows-Appliances gemeldet (auch wenn E/A ununterbrochen generiert wird): gelesene/geschriebene Bytes gesamt, Anzahl der Lese-/Schreibvorgänge auf dem Volume, bei Lese-/Schreibvorgängen verstrichene Zeit. Dies liegt an einem Fehler in der Windows-perfmon-API - Die Null-Werte sind die Werte, die von der Windows-perfmon-API gemeldet werden.
Anders als der Filer-MSI sollte die japanisch lokalisierte Windows-Version unter CA AppLogic funktionieren.
Eine Windows-Appliance kann nicht starten, wenn das virtuelle DVD-ROM-Gerät MagicISO installiert ist. Virtuelle DVD-ROM-Geräte werden momentan in CA AppLogic für Windows-basierte Appliances nicht unterstützt.
Ab und zu dauert es einige Minuten, bis Windows neue NICs im Inneren einer Appliance erkennt. Dies geschieht, wenn der Benutzer Terminals für einen Windows-Appliance-Singleton hinzufügt/entfernt. Die zusätzliche Zeit, die für die Erkennung dieser neuen NICs benötigt wird, kann zu einer Zeitüberschreitung beim Starten der Appliance führen. Um dieses Problem zu umgehen, erhöhen Sie das Zeitüberschreitungslimit für das Starten Ihrer Windows-Appliance.
Wenn ein Benutzer eine Windows-Appliance auf seinem Grid hat und die Appliance auf ein anderes Grid migrieren möchte, das eine andere Hardware hat, muss die Windows-Appliance möglicherwiese erneut aktiviert werden (erneute Aktivierung in Microsofts Windows). Die erneute Aktivierung wird ausgelöst, wenn sich ein bestimmter Teil der Hardware geändert hat (CA weiß hier nicht genau, welche Hardware-Änderungen die erneute Aktivierung auslösen). Beachten Sie, dass für die erneute Aktivierung ein Zugriff auf das Internet von innerhalb der Windows-Appliance erforderlich sein kann. Dieses bestimmte Problem wurde beobachtet, nachdem die Größe des Startvolumes einer Windows-Appliance geändert und die Appliance auf ein anderes Grid migriert wurde.
Dieses Problem betrifft nur Windows 2008 Server 32/64-Bit (Windows 2003 Server funktioniert korrekt). Beim Zugriff auf ein Windows-2008-Volume über den Filer oder über "ssh" zu einer Appliance ist der Benutzer aufgrund von Berechtigungsproblemen möglicherweise nicht in der Lage, auf Dateien zuzugreifen bzw. Dateien zu ändern. Um über die Befehls-Shell auf Dateien zuzugreifen bzw. Dateien zu ändern, melden Sie sich über die grafische Konsole beim Windows-Desktop an, und öffnen Sie eine Befehls-Shell. Die Befehls-Shell kann verwendet werden, um auf Dateien zuzugreifen bzw. Dateien zu ändern.
Windows 2003-Server löst während der Installation beim erstmaligen Starten eine Zeitüberschreitung aus. Führen Sie die Windows-Build-Anweisungen zur Umgehung dieses Problems genau aus.
Bei der Installation eines Turbogate-PV-Treibers muss sich der Benutzer, wenn die Appliance auf einem Xen-basierten Grid-Server ausgeführt wird, beim ersten Start der Appliance manuell durch den Hardware-Setup-Assistenten für die Installation der Turbogate-PV-Treiber aller in der Appliance konfigurierten Terminals klicken. Andernfalls schlägt die Appliance beim Starten fehl.
Beim Erstellen einer neuen 32-/64-Bit-Windows 2003-Server-Appliance funktioniert die Appliance nur auf einem Grid-Server, der den gleichen Hypervisor verwendet, auf dem die Appliance anfänglich erstellt wurde. Andernfalls stürzt die Appliance während des Startens ab. Wenn die Appliance beispielsweise anfänglich auf einem ESX-basierten Grid-Server erstellt wurde, kann die Appliance zum Beispiel nur auf einem ESX-basierten Grid-Server verwendet werden. (Der Versuch, die Appliance auf einem XEN-basierten Grid-Server zu verwenden, wird scheitern und die Appliance wird während des Startens abstürzen.)
Dies ist ein bekanntes Problem mit Microsoft Windows 2003 Server. Microsoft löst dieses Problem mit Ihrer Windows-2003-Appliance.
Die Probleme in der folgenden Liste wurden in den Versionen von CA AppLogic 2.4-3.x beobachtet, sind aber äußerst schwierig zu reproduzieren (wenn überhaupt) und wurden auch nur einmal oder zweimal beobachtet. Wenn eines dieser Probleme auf Ihrem Grid erscheint, senden Sie einen Fehlerbericht an CA, in dem beschrieben wird, welches Problem auftrat und welche CA AppLogic-Befehle ausgeführt wurden, die dann zu dem Fehler geführt haben.
Ein Server im Grid startete aufgrund eines Absturzes im Linux-Kernel in dom0 des Servers eigenmächtig neu. Dies würde nicht zu einem Ausfall des gesamten Grids führen, wie in früheren Versionen von CA AppLogic; es kann aber zu Ausfallzeiten der Anwendung kommen. In solch einem Fall startet CA AppLogic die Appliances, die auf dem fehlerhaften Server ausgeführt wurden, auf anderen Servern im Grid neu. Wenn dieses Problem auf Ihrem Grid beobachtet wird, wenden Sie sich an den CA Support.
In CA AppLogic 2.4 hat es einige Fälle gegeben, in denen ein Server die Verbindung mit der Grid-Steuerung verliert und neu startet. Dies führt dazu, dass alle Appliances, die auf dem Server ausgeführt werden, auf anderen Servern im Grid erneut geplant werden, wodurch es zu Ausfallzeiten der Anwendung kommen kann. Es ist nicht bekannt, warum die Server die Verbindungen mit der Grid-Steuerung verlieren. In CA AppLogic 2.7-3.x versucht der Server – wenn die Verbindung des Servers mit der Grid-Steuerung aufgelöst wird –, die Verbindung mit der Grid-Steuerung wiederherzustellen. Wenn dies erfolgreich ist, bleibt der Server in Betrieb, und es gibt keine Anwendungsausfallzeit. Wenn der Server innerhalb von 1 Minute die Verbindung mit der Grid-Steuerung nicht wiederherstellen kann, wird der Server neu gestartet, und es kommt zu Ausfallzeiten der Anwendung. Wenn ein Server seine Verbindung mit der Grid-Steuerung verliert, wird eine Meldung zum Dashboard protokolliert. Wenn dieses Problem beobachtet wird, wenden Sie sich umgehend an den CA Support.
Bei CA AppLogic 2.7/2.8 schlägt die gleichzeitige Größenänderung aller 4 NTFS-Volumes fehl. Dieses Problem ist nur einmal beobachtet worden.
Während NASR eine 800-MB-Datei auf einem 1-GB-Volume reproduzierte, hörte die NASR-Appliance auf zu antworten. CA kann dieses Problem nicht reproduzieren. Wenn dieses Problem auf Ihrem Grid gefunden wird, benachrichtigen Sie den CA-Support.
Ein Benutzer hat mehr als 6 grafische Konsolen für unterschiedliche Windows-Appliances geöffnet, die auf dem Grid ausgeführt wurden (gleichzeitig geöffnet). Beim Öffnen der 7. grafischen Konsole startete einer der Server neu und schloss sich dem Grid neu an. Die Appliances, die auf dem ausgefallenen Server ausgeführt wurden, wurden auf anderen Servern innerhalb des Grids neu gestartet. Dieses Problem ist nur einmal beobachtet worden.
Wir haben die folgenden bekannten Probleme mit dem Backbone Fabric Controller (BFC) in dieser Version identifiziert:
su - bfcadmin
Wichtig! Nachdem diese Abhängigkeit aufgehoben wurde, wird Ihr System ohne Replikat ausgeführt. Sie werden daher in die Benutzeroberfläche zurückgehen wollen, um an dem gleichen oder einem unterschiedlichen Speicherort ein anderes Replikat zu erstellen.
Verwenden Sie den Befehl "3t grid shutdown" nicht auf einem Grid.
In diesem Fall sollte ein “service nfs restart” das Problem beheben.
Wenn Sie diese Meldung erhalten, betätigen Sie einfach die Escape-Taste, um mit der Installation fortzufahren.
In CA AppLogic 3.5 geben einige Broadcom Corporation NetXtreme II NICs die falsche Meldung aus, dass sie zu langsam sind. Bei Auftreten dieses Fehlers können Sie versuchen, den Server neu ermitteln zu lassen.
Wenn die Speicherkapazität des BFC erschöpft ist, bevor er heruntergefahren werden kann, müssen Sie den BFC nach der Freigabe von Speicherplatz neu starten, damit er wieder ordnungsgemäß funktioniert.
Wenn Sie bei dieser Version des Produkts eine unbeaufsichtigte Installation durchführen, darf Ihr Kennwort nicht das Zeichen "=" enthalten
Wenn Sie in AppLogic 3.1 im BFC VLAN 0 verwendet haben, können Sie diese VLAN-ID zwar weiterverwenden, aber dieses VLAN auf der Benutzeroberfläche ab 3.5 nicht mehr zuweisen.
Aufgrund dieses Fehlers können gelegentlich Server in Grids aufgenommen werden, die gesperrt werden sollten. Wenn die Ports ordnungsgemäß konfiguriert sind, tritt dieses Problem auf.
Wenn Sie mehr als 256 Zeichen verwenden müssen, teilen Sie diese Parameter einfach auf mehrere Aktualisierungen des Grid auf.
Wenn Sie eine Bare Metal-Installation verwenden und versuchen, ein Replikat in einem über NFS bereitgestellten Dateisystem zu definieren, tritt ein Problem auf, wenn der Eigentümer des Verzeichnisses nicht "bfcadmin" ist. Eine einfache Option besteht darin, das Replikat nach der Installation über die Benutzeroberfläche hinzuzufügen. Eine weitere Option ist die folgende Vorgehensweise:
groupadd -g 64869 bfc useradd -u 64870 -g 64869 bfcadmin
chown bfcadmin /mnt/replica chgrp bfc /mnt/replica
(Hierbei ist "/mnt/replica" der Pfad zum Replikatsverzeichnis.)
Auf einigen Servern wird vom System dieselbe CPU-Anzahl gemeldet, wenn Hyper-Threading deaktiviert ist und wenn es aktiviert ist. Dies ist wurde bei einigen Dell R610-Servern beobachtet.
Dieses Problem beruht darauf, wie Parameter in die an "aldo set" übergebene Konfigurationsdatei geschrieben werden. Wenn der Benutzer auf der Benutzeroberfläche Daten mit einem Komma zwischen Einträgen eingibt, tritt derselbe Fehler auf. Die Umgehungslösung für die BFC-API besteht darin, nur eine einzige Zeichenfolge mit einem Zeilenumbruchtrenner zwischen den Einträgen zu übergeben.
Zum Beispiel:
\"additional_config\":[\"ext_dns1=155.35.34.108\next_dns2=141.202.1.108\"]
anstelle von:
\"additional_config\":[\"ext_dns1=155.35.34.108\",\"ext_dns2=141.202.1.108\"]
Das Problem tritt auf, wenn das Spanning Tree-Protokoll (STP) auf den externen Switches aktiviert ist und das nicht markierte VLAN an dem Switch-Port, der mit der externen Serverschnittstelle verbunden ist, nicht mit dem nicht markierten VLAN des Switch-Ports identisch ist, der mit der externen Schnittstelle der BFC-Server verbunden ist. Die Einstellung "stp_port" der externen Serverschnittstelle wird dann auf unbekannt festgelegt, und der Server wird in Quarantäne gestellt. Deaktivieren Sie als Umgehungslösung entweder STP auf den externen Switches vollständig, oder konfigurieren Sie das nicht markierte VLAN des Switch-Ports, der mit der externen Schnittstelle der Server verbunden ist, so, dass es mit dem nicht markierten VLAN des Ports identisch ist, der mit der externen Schnittstelle der BFC-Server verbunden ist. Heben Sie dann die Quarantäne des Servers auf, um den Discovery-Prozess neu zu starten.
Dieses Problem tritt auf, weil das Löschen eines Subnetzes in 3.1 nicht ordnungsgemäß fehlschlägt, wenn Sie über Grids mit Anwendungs-IP-Adressbereichen verfügen, die sich in diesem Subnetz befinden. Beim Upgrade-Vorgang wird nach dem fehlenden Subnetz gesucht, und das Upgrade schlägt dann fehl, weil das Subnetz nicht vorhanden ist. Verwenden Sie als Umgehungslösung beim fehlgeschlagenen Upgrade die Anweisungen für die Wiederherstellung Ihrer vorherigen 3.1 BFC-Installation. Wechseln Sie dann zu den einzelnen Grids, und entfernen Sie alle Anwendungs-IP-Adressbereiche aus dem Grid, die nicht zu einem gegenwärtig konfigurierten Subnetz gehören. In bestimmten Fällen, beispielsweise wenn Sie später dasselbe Subnetz mit einem neuen Parameter für die CIDR-Präfixlänge erneut hinzugefügt haben, liegt der Bereich möglicherweise innerhalb der Grenzen eines aktuellen Subnetzes, die zugrunde liegende Subnetzkomponente ist jedoch falsch und führt weiterhin zum Fehlschlagen des Upgrades. Um sicherzugehen, sollten Sie sich vergewissern, dass das Subnetz im BFC mit den Parametern des Anwendungs-IP-Adressbereichs auf der Benutzeroberfläche der Grid-Steuerung übereinstimmt.
Der Parameter "isotool -o" zeigt die USB-Geräte, die zum Rechner (CentOS 5.5-Box) hinzugefügt sind, nicht richtig an. Dies ist ein bekanntes Problem mit CentOS 5.5. Zur Behebung dieses Problems müssen Sie den folgenden Shellbefehl als root-Benutzer ausgeben:
service haldaemon restart
| Copyright © 2012 CA. Alle Rechte vorbehalten. |
|