Guten Abend zusammen,
eine kl. Denksportaufgabe nach dem langen, sonnigen Wochenende.
Ich mache mir zurzeit Gedanken, wie wir die Windows Server mit dem Modul Large Files des NSP hochverfügbar bereitstellen können. Die einzige Architektur die mir bisher technisch gefällt, sieht wie folgt aus.
Zwei virtuelle Maschinen bei einem Anbieter. Dieser stellt die Maschinen in zwei unterschiedlichen Verfügbarkeitszonen bereit. Am besten natürlich separate Rechenzentren. Das Frontend für die Anwender soll ein Load Balancer (as a Service) sein. Dieser verteilt die Anfragen an die beiden (Backend) Servern. Über verschiedene Mechanismen wird die Verfügbarkeit regelmäßig überprüft. Gerade bei einen ungewollten Ausfall oder Wartungsarbeiten (z.B. Microsoft Updates) merkt der Anwender erst einmal nichts davon.
Der Load Balancer soll auf Layer 4 NAT agieren. D.h. die Verbindungen laufen über den Load Balancer und die Backend Server sind für den Anwender nicht direkt ersichtlich. Wer natürlich die kryptischen DNS-Namen der Backend Server ausfindig macht, kann natürlich weiterhin direkt zugreifen. Das entsprechende Tool gibt es heutzutage im Internet... aber zurück zum Thema.
Die Kommunikation seitens NSP erfolgt laut TCP Dump nicht über den DNS-Namen in den Einstellungen (externer HTTPS Adresse). Sondern NSP greift auf die dedizierten DNS-Namen der Server zurück. Somit sind beim Hochladen einer Datei durch NSP der LB auch keine Komponenten, die evtl. Probleme verursachen können. Jeder der beiden Server hat seine eigene Microsoft SQL Datenbank lokal liegen. D.h. es gibt auch hier keine Überschneidungen. Ist ein Server nicht verfügbar, so werden die fehlenden Dateien hinterher problemlos synchronisiert. Soweit so gut...
Gibt es in meinen Überlegungen einen Denkfehler? Wabe ich etwas Elementares übersehen? Wie sieht Unabhängig von meinen Erläuterungen ein Best Practice aus? Ich freue mich über Meinungen und Anregungen.
Schönen Feierabend!
Daniel
eine kl. Denksportaufgabe nach dem langen, sonnigen Wochenende.
Ich mache mir zurzeit Gedanken, wie wir die Windows Server mit dem Modul Large Files des NSP hochverfügbar bereitstellen können. Die einzige Architektur die mir bisher technisch gefällt, sieht wie folgt aus.
Zwei virtuelle Maschinen bei einem Anbieter. Dieser stellt die Maschinen in zwei unterschiedlichen Verfügbarkeitszonen bereit. Am besten natürlich separate Rechenzentren. Das Frontend für die Anwender soll ein Load Balancer (as a Service) sein. Dieser verteilt die Anfragen an die beiden (Backend) Servern. Über verschiedene Mechanismen wird die Verfügbarkeit regelmäßig überprüft. Gerade bei einen ungewollten Ausfall oder Wartungsarbeiten (z.B. Microsoft Updates) merkt der Anwender erst einmal nichts davon.
Der Load Balancer soll auf Layer 4 NAT agieren. D.h. die Verbindungen laufen über den Load Balancer und die Backend Server sind für den Anwender nicht direkt ersichtlich. Wer natürlich die kryptischen DNS-Namen der Backend Server ausfindig macht, kann natürlich weiterhin direkt zugreifen. Das entsprechende Tool gibt es heutzutage im Internet... aber zurück zum Thema.
Die Kommunikation seitens NSP erfolgt laut TCP Dump nicht über den DNS-Namen in den Einstellungen (externer HTTPS Adresse). Sondern NSP greift auf die dedizierten DNS-Namen der Server zurück. Somit sind beim Hochladen einer Datei durch NSP der LB auch keine Komponenten, die evtl. Probleme verursachen können. Jeder der beiden Server hat seine eigene Microsoft SQL Datenbank lokal liegen. D.h. es gibt auch hier keine Überschneidungen. Ist ein Server nicht verfügbar, so werden die fehlenden Dateien hinterher problemlos synchronisiert. Soweit so gut...
Gibt es in meinen Überlegungen einen Denkfehler? Wabe ich etwas Elementares übersehen? Wie sieht Unabhängig von meinen Erläuterungen ein Best Practice aus? Ich freue mich über Meinungen und Anregungen.
Schönen Feierabend!
Daniel
