5 Gründe, warum? WAN Die Optimierung hat sich über Anwendungs-Proxys hinaus entwickelt

Anwendungs-Proxys verstehen
Ein Anwendungs-Proxy war eine Software, die in die Mitte eines Anwendungsdatenstroms eingefügt wurde (im Allgemeinen zwischen den Schichten 4 und 7 des OSI-Modells), als Unterlage, um eine Eigenschaft der Anwendung zu „reparieren“, die zu einer schlechten Leistung führte über ein WAN Verbindung. Diese „Korrekturen“ gab es in der Regel in zwei Varianten:

• Diejenigen, die dazu beigetragen haben, die Datendeduplizierung der Anwendungsdaten zu ermöglichen; oder
• Diejenigen, die dazu beigetragen haben, den Gesamtumfang der Kommunikation („Geschwätzigkeit“) zu reduzieren, der von zwei Anwendungsendpunkten über einen Zeitraum von einem Jahr benötigt wird WAN Verbindung.

Anwendungs-Proxys (von herkömmlichen verwendet WAN Optimierungsanbieter wie Riverbed sind veraltete Technologien und werden in der Welt immer seltener eingesetzt WAN Optimierungsraum heute.

Und hier sind die fünf wichtigsten Gründe für diesen Übergang:

1) Anwendungs-Proxys neigen stark dazu, viele der Anwendungen, die sie angeblich unterstützen, zu „kaputt machen“.

Dies ist bei weitem der Hauptgrund dafür WAN Die Optimierungstechnologie hat sich weitgehend vom „Layer-7-Proxy“-Modell entfernt.

Ein Anwendungs-Proxy muss gemäß der genauen Spezifikation des Anwendungsprotokolls geschrieben werden. Dies ist im Allgemeinen für stabile Protokolle auf niedrigerer Ebene in Ordnung, z SSL, aber es wird zu einem Problem für höherstufige, proprietäre Protokolle wie MS-SQL oder Citrix ICA. Diese Protokolle ändern sich häufig und die Änderungen werden nicht veröffentlicht.

Wie es in der Welt des Netzwerkadministrators so oft vorkommt, wird irgendwo ein Server aktualisiert, und der erste Hinweis darauf, dass sich ein Anwendungsprotokoll geändert hat, kommt, wenn die Beschwerden der Benutzer eintreffen, dass die Anwendung nicht mehr ordnungsgemäß funktioniert.

Sobald der Anwendungs-Proxy als Ursache für den Fehler identifiziert wurde, muss der Proxy aktualisiert werden, damit er mit der neuen Anwendungsversion kompatibel ist. Und da diese Protokolle häufig vom Proxy-Anbieter rückentwickelt werden müssen, kann die „Behebung“ für diesen Fehler viele Monate oder länger dauern (je nachdem, ob sie als „weit verbreitet“ gilt), bevor sie verfügbar ist.

Dadurch bleiben dem Netzwerkadministrator nur zwei Möglichkeiten: 1) Teilen Sie dem Serveradministrator mit, dass das Netzwerk die neue Anwendungsversion nicht unterstützt; oder 2) Stellen Sie die Anwendungs-Proxys so ein, dass sie die neue Anwendung ignorieren (umgehen) und die Anwendung im Wesentlichen ohne jegliche Optimierung rendern.

2) Ein bestimmtes Protokoll wird langsam nicht mehr verwendet.

Ein Beispiel für diese Art von Übergang findet heute bei einigen proprietären verschlüsselten Protokollen wie MAPI statt. MAPI ist das proprietäre Exchange Server-E-Mail-Protokoll von Microsoft, es wurden jedoch weitere Funktionen entwickelt cloud-basiert und SaaS Anwendungen SSL entwickelt sich schnell zum Unternehmensprotokoll der Wahl für SOHO- und mobile Benutzer. Und da unterstützt Microsoft auch SSL Für ihre Exchange-E-Mail-Zustellung wechseln viele Unternehmen von MAPI hin zu nicht-proprietären Lösungen SSL. Da sich Anwendungen von proprietären Protokollen entfernen, werden diese Arten von Proxys obsolet.

3) WAN Die Optimierungstechnologie hat sich so weit entwickelt, dass kein spezifischer Proxy mehr erforderlich ist.

NFS ist ein gutes Beispiel. NFS v3 hatte als Dateifreigabeprotokoll bestimmte Einschränkungen hinsichtlich des Durchsatzes und der Reaktionszeit des Endbenutzers WAN Latenzen. Dies lag vor allem an der Art und Weise, wie das Protokoll entworfen wurde, wodurch die Datenmenge begrenzt wurde, die gleichzeitig übertragen werden konnte, ohne dass Anwendungsantworten eingingen.

Gleichzeitig vorhanden WAN Optimierungstechnologien konzentrierten sich in erster Linie auf die Datendeduplizierung als Methode zur Reduzierung der Gesamtdatenmenge, die über das Internet hin- und hergesendet werden muss WANund dadurch Staus beseitigen, um die Reaktionszeit zu verbessern. Aber diese sind älter WAN Optimierungstechnologien verwendeten eine Form der Deduplizierung auf Blockebene, die beim NFS-Verkehr nicht besonders gut funktionierte, da es für die Zuordnung eines Datenblocks hilfreich ist zu wissen, wo der Datenteil einer Übertragung beginnt. Der Speicherort des Datenteils innerhalb einer NFS-Protokollübertragung kann variieren.

Die damals beste Lösung, um das NFS zu „reparieren“. WAN Das Problem bestand darin, einen Anwendungs-Proxy zu schreiben, der die für das Protokoll erforderliche Kommunikationsmenge künstlich verringert und außerdem herausfindet, wo sich der Datenanteil der NFS-Übertragung befindet, damit die Deduplizierung auf Blockebene effektiv sein kann.

Traditionelle WAN Optimierungsanbieter benötigen immer noch einen Shim für die NFS-Optimierung, da sie immer noch die ältere Deduplizierungstechnologie verwenden, aber neuere Anbieter können den NFS-Verkehr optimieren, ohne dass ein anwendungsspezifischer Proxy erforderlich ist, und eine minimale Proxy-Optimierung bedeutet, dass in Ihrem Netzwerk weniger Probleme auftreten!

4) Einige Anwendungen oder Protokolle, die über a nicht gut funktionierten WAN Verbindung vor 10 Jahren wurden weiterentwickelt oder neu gestaltet, sodass sie über a funktionieren können WAN ohne Zwischenscheibe.

Schauen wir uns noch einmal NFS an. Spulen wir heute vor – die späteren Versionen von NFS v4.x haben die meisten Protokolleinschränkungen in Bezug auf Chattiness und Durchsatz behoben. Die übrigen Grenzwerte werden durch Generic aufgelöst TCP Optimierung, ohne dass eine anwendungsspezifische Unterlage erforderlich ist.

5) Eine „Application Proxy“-Technologiearchitektur ist aus Geschäfts- und Entwicklungssicht kein nachhaltiges Modell.

Erstens ist die Wartung sehr teuer. Jedes Mal, wenn neue Versionen von Anwendungen oder deren Updates von den Anwendungsanbietern veröffentlicht werden, müssen neue spezifische Optimierungsmechanismen für den Anwendungs-Proxy entwickelt werden.

Nehmen wir zum Beispiel Citrix ICA – sie besitzen das Protokoll und können jederzeit Änderungen an der Protokollspezifikation vornehmen; von Release zu Release oder sogar innerhalb eines Service Pack-Updates. Den Überblick über all diese Anwendungs-Proxys zu behalten und weiterhin veraltete Protokolle zu unterstützen, ist kein sehr effizientes Geschäftsmodell.

Es schränkt auch die zukünftige Skalierbarkeit ein. Die eigentliche Natur eines Proxys besteht darin, im Namen des Remote-Servers zu agieren. Dazu muss der Proxy jede Anwendungssitzung beenden und verfolgen. Dies führt zu einem sehr hohen Mehraufwand an Hardware-Anforderungen, was dazu führt, dass immer größere Boxen benötigt werden.

Glücklicherweise werden die Probleme, die einst durch Proxys auf Anwendungsebene gelöst wurden, jetzt auf effizientere Weise gelöst, wodurch einige der ursprünglichen Vorteile der alten Proxy-Technologie obsolet werden. Es gibt immer noch einige Protokolle der Anwendungsschicht, wie z. B. ältere Versionen von CIFS oder SMB, die von einem spezifischen Proxy zur Optimierung profitieren WAN, aber diese Liste wird immer kürzer. Durch die Verringerung der Abhängigkeit von bestimmten Proxys auf Anwendungsebene kann die heutige Technologie eine bessere Optimierung ermöglichen und gleichzeitig die Zuverlässigkeit verbessern und potenzielle Fehlerquellen beseitigen.