Dieses Kapitel enthält folgende Themen:
Bekannte Probleme und Beschränkungen
Hinweis: Alle Solaris-basierten Appliances wurden ab CA AppLogic® 3.7 entfernt.
Wichtig! Wir empfehlen strengstens, dass Sie die mit der CA AppLogic®-GUI bereitgestellte Web-Shell verwenden.
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.
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.
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.
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 (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.
Stattdessen kann jeder andere Browser verwendet werden.
Freigegebene Schnittstellen sollten mit allen anderen Betriebssystemen funktionieren.
Folgende Probleme sind für diese Version bekannt:
Während das Grid und die Grid-Steuerung selbst unter hoher Belastung stehen, können verschiedene Grid-Steuerungs-Befehle (zum Beispiel "app provision" oder "vol resize") fehlschlagen und Netzwerkfehler in der GUI auftreten. Wenn dieses Problem auftritt, vergrößern Sie die Grid-Steuerungs-CPU auf 1 und den Speicher auf mindestens 2 GB. Dies sollte das Problem umgehen.
Dieses Problem wird in einer nachfolgenden Version behoben.
Um dieses Problem zu umgehen, heben Sie die Fixierung der Appliance auf, und starten Sie die Anwendung neu. Dieses Problem wird in einer nachfolgenden Version behoben.
Derzeit unterstützt der Filer nicht das gleichzeitige Verwalten zweier ext3-Snapshot-Volumes. Dieses Problem wird in einer künftigen Version behoben werden.
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.
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. Beachten Sie, dass dieses Problem nicht in CA AppLogic® 3.5 oder 3.7 beobachtet wurde.
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 Grid 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®-Infrastruktur-Editor 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.
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.
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 Grid 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 Grid neu zu starten, wird dieses Problem vermeiden.
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.
Es kann in seltenen Fällen vorkommen, dass das Upgrade auf 3.7 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.7 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.
Hinweis: Dies könnte sich ebenso auf die 3.7-Version auswirken.
Während der Größenänderung von sehr großen NTFS-basierten Volumes (viele GBs), wird unter Umständen der Fortschritt der Größenänderungen nicht mehr angezeigt oder scheint stecken geblieben zu sein. Die Größenänderung läuft jedoch weiterhin und wird erfolgreich abgeschlossen werden. Dieses Meldeproblem wird in einer künftigen Version behoben werden.
Seit CA AppLogic® 3.1+ hat sich die Leistung des megaraid-SAS-Treibers verschlechtert, der nun etwa 75 % langsamer arbeitet als ein physischer Server. CA arbeitet derzeit daran, dieses Problem zu lösen, und wird einen Hotfix veröffentlichen, sobald das Problem identifiziert und behoben wurde. Bis zur Lösung dieses Problems wird empfohlen, einen anderen Datenträgercontroller-Typ zu verwenden.
Derzeit können Windows 2008 DataCenter-Appliances nicht gestartet werden, wenn sie so konfiguriert sind, dass mehr als 8 CPUs verwendet werden (nur bei Xen-basierten Grids). Dieses Problem wird in einer künftigen Version behoben werden.
Beim Upgrade von Cygwin tritt ein Fehler auf, während ein Upgrade auf das aktuelle Windows-APK durchgeführt wird, das mit CA AppLogic® 3.7 ausgegeben wird. Bis zur Behebung dieses Problems wird empfohlen, eine neue Windows-Appliance zu erstellen, anstatt ein Upgrade durchzuführen. Dieses Problem wird in einer künftigen Version behoben werden.
Wenn 3t-Befehle über ssh ausgeführt werden, werden die Parameter entweder auf eine Leerstelle oder auf ein Backtick (`) aufgeteilt, je nach der Art und Weise, auf die der Befehl aufgerufen wird. Wenn ein 3t-Befehl über einen Eigenschaftswert mit einer Leerstelle verfügt, werden die Zeichen nach der Leerstelle fälschlicherweise als separates Argument behandelt. Dieses Problem wird in einer künftigen Version behoben werden.
Die http_port-Eigenschaft wird ignoriert, daher wird der Port immer 8080 sein. Dieses Problem wird in einer künftigen Version behoben werden.
Bei Versuchen, mehr als 90 HVM-basierte Appliances auf Xen-basierten Grids zu starten, können Bereitstellungs- oder Appliance-Startfehler ausgegeben werden. Dabei handelt es sich um ein bekanntes Problem, das in einer zukünftigen Version behoben wird.
Verwenden Sie eine ältere Safari-Version, oder informieren Sie sich unter dem folgenden Link über eine mögliche Umgehung des Problems.
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.
32-Bit-Version von Windows 8 wird derzeit nicht von den Halsign-Turbogate-Treibern unterstützt. Allerdings wird die 64-Bit-Version von Windows 8 unterstützt. Dieses Problem wird in einer nachfolgenden Version behoben.
Das Windows-APK entdeckt derzeit duplizierte Zuweisungen von IP-Adressen nicht richtig. Daher hängt es vom Benutzer ab, festzustellen, ob versehentlich duplizierte IP-Adressen zugewiesen wurden. Dieses Problem wird in einer nachfolgenden 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® 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 Grid 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® 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® 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 Grid 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.
Wenn Sie bei dieser Version des Produkts eine unbeaufsichtigte Installation durchführen, darf Ihr Kennwort nicht das Zeichen "=" enthalten
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 die Wiedergabeoption für Grafiken in Internet Explorer 9 nicht richtig festgelegt ist, werden Diagramme im BFC nicht richtig angezeigt. Betroffene Diagramme werden im BFC-Dashboard und auf den Seiten "Grids" und "Server" angezeigt.
Um dieses Problem zu beheben, klicken Sie in Internet Explorer 9 im Menü "Tools" auf "Internetoptionen". Klicken Sie auf die Registerkarte "Erweitert", und gehen Sie in den Abschnitt "Grafikkarte mit Beschleunigung". Aktivieren Sie das Kontrollkästchen "Softwarerendering verwenden". Speichern Sie Ihre Änderungen, und starten Sie IE neu.
Wenn Sie diese vielen MACs auf den Modus "AutoDiscovery" (Negativliste) festlegen müssen, wäre es am besten, den Modus "Manuelle Konfiguration" (Positivliste) mit 3.5 zu verwenden.
Stellen Sie sicher, dass externe IP-Adressen verfügbar sind, wenn Sie einem BFC Server hinzufügen.
Aufgrund dieses Fehlers können Sie die Steuerungs-IPs und Anwendungs-IPs nicht in einem Schritt direkt miteinander austauschen. Wenn Sie diesen Austausch durchführen müssen, legen Sie zuerst andere Werte für die IPs fest, anschließend können Sie sie erneut auf die geplanten Werte festlegen.
Wenn Sie versuchen, über die API ein mit Tag versehenes Netzwerk in ein Grid ohne Tag hinzuzufügen, dann ist der Aufruf erfolgreich, statt "400 Ungültig Anforderung" zurückzugeben.
Wenn kein Download-Server (lokales Download-Verzeichnis) konfiguriert ist, werden Versionen als "Heruntergeladen" angezeigt. Die Löschvorgänge werden akzeptiert, aber der Löschvorgang wird nicht ausgeführt. Künftige Versionen werden einen Fehler generieren, der erklärt, warum dieser Vorgang nicht ausgeführt wird.
Dies ist kein tatsächlicher Fehler, sondern eine verwirrende Meldung.
Sie können die API verwenden, um den gleichen Bereich mehrmals hinzuzufügen, aber Sie können die Benutzeroberfläche nicht verwenden, um die duplizierten Bereiche zu entfernen. (Es treten keine Probleme auf, wenn duplizierte Bereiche nicht entfernt werden.)
Da 3.7.0 nicht lokalisiert wurde, werden in den neuen Anwendungsteilen nur englische Zeichenfolgen angezeigt. In den zuvor lokalisierten Anwendungsteile (die, die in 3.5 vorhanden waren) werden nicht-englische Zeichenfolgen wie vorher angezeigt.
Auf einiger Dell-Hardware können Sie eine DRAC BIOS-Option für virtuelle Datenträger aktivieren. Mit dieser Funktion können Sie von einem virtuellen Datenträgergerät über das Netzwerk booten. Allerdings kann der CA AppLogic®-Kernel das virtuelle Datenträgergerät als SCSI-Gerät identifizieren und den Boot-Gerätenamen verwechseln, sodass aus "sda" "sdb" wird.
Um dieses Problem zu verhindern, deaktivieren Sie die virtuelle Datenträgeroption des DRAC im DRAC BIOS auf Ihrer Dell-Hardware.
Wenn Sie der Liste mit MAC-Adressen im BFC Adressen hinzufügen oder daraus entfernen, beschränken Sie die Höchstanzahl auf 500. Die MAC-Adressliste wird im Discovery-Modus verwendet, um Server einzuschließen (bei manueller Konfiguration) oder um Server auszuschließen (im Auto-Discovery-Modus).
Sie können auf der Seite "Verwaltung" des BFC auf der Registerkarte "Discovery" mit der MAC-Adressliste arbeiten. Sie können die Serverliste bearbeiten oder eine Datei mit einer Liste von Servern importieren. Sie können die MAC-Adressliste auch mithilfe der BFC API festlegen.
Während AppLogic-Xen-Grid-Server 3-TB-Festplatten unterstützen, unterstützen AppLogic ESX-Grid-Server maximal 2-TB-Festplatten. Server mit 3-TB-Festplatten sollten nicht für die Ausführung des ESX-Hypervisors ausgewählt werden, da ansonsten die Grid-Erstellung fehlschlagen wird.
Wenn Sie am CA AppLogic® 3.7-Betaprogramm teilgenommen haben, müssen Sie sicherstellen, dass die Betaversion von CA AppLogic® im Download-Verzeichnis des BFC verfügbar ist, wenn Sie einen Rückgriff aufgrund eines fehlgeschlagenen Upgrades ausführen müssen.
|
Copyright © 2013 CA.
Alle Rechte vorbehalten.
|
|