Skalierung / Planung Webprojekt

Question

Hallo liebe Developer-Community,

 

ich plane gerade ein neues Webprojekt, welches ich selbstverständlich ;-D mit ASP.net realisieren möchte. Das System soll verschiedene Kriterien erfüllen. Ich habe mir jetzt ein Konzept überlegt. Ich benötige 3 Gruppen von Benutzern. Einen High-Access-Admin (Zugriff auf Alles) , einen "Lower-Access-Admin" (Repräsentiert Verwalter im System) und Schlussendlich den Benutzer, der das System schlicht nutzen darf und einen seinen Bedürfnissen entsprechenden Account hat. Jetzt will ich das Projekt für viele Benutzer bereitstellen. Dazu muss ich in der Lage sein, eine gewisse Serververteilung zu erreichen. Es wird die Hauptseite des Projektes geben (die nur zum Anmelden, Vorstellen der Seite, Werbung, FAQs usw. dient). Ich würde dazu eine einfache ASP.net Webforms Application erstellen, die auf einem Mittelklasse Webserver läuft. Für angemeldete User würde ich ein Backend zur Verfügung stellen, das ich auf anderen Mittelklasse - Webservern mit großer Bandbreite zur Verfügung stelle. Nun will ich hier einen Schnitt machen. Die eigentlichen Arbeitsprozesse der Webseite sollen auf High-Performance-Servern als Web-Service ablaufen. Dazu frage ich mich nun ob ASP.net Webservices geeignet wären, mit denen die Backend-UI auf den anderen Servern kommuniziert. Zudem soll jeder Benutzer eine unabhängige Seite für sich beanspruchen können, die vom "Arbeitsserver", also vom Webservice konfiguriert wird und dort auch liegt. Diese vom Benutzer unabhängige Seite würde ich allerdings dann in ASP.net MVC erstellen, da die Template-Engines mich sehr ansprechen und vom Prozess her dem Benutzer Flexiblität gewährleistet werden kann. Diese Splittung in UI-und Working-Server soll nicht nur dem Load Balancing dienen, sondern auch der Benutzerverwaltung. Ich möchte jedem Benutzer auf einem Server eine gewisse Leistung bereitstellen. Es ist  sehr verlockend zu sagen, wenn sich ein neuer Benutzer registriert, fragt die Backend-UI (die alle server kennt) einfach nach, auf welchem System am wenigsten User sind, und legt ihn dort an. Die Server sind untereinander verbunden.

 

Was haltet ihr davon? Gibt es möglicherweise Probleme? Hat jemand Verbesserungsvorschläge? Ich wäre über eine Ideen anregende Diskussion sehr erfreut.

 

Viele Grüße

Answer 1

Hallo ´.net-tier,

>>Hat jemand Verbesserungsvorschläge?

Du solltest über den Einsatz der Windows Azure Plattform nachdenken, anstatt Pläne zu schmieden alles neu zu erfinden. Ansonsten fällt mir bei deiner doch recht allgemein gehaltenen Architekturbeschreibung (es fehlen die Details im Anwendungsszenario) auf, Du machst keine Angaben zur Datenhaltung (z.B. Benutzerverwaltung), keine Angaben zur Verwaltung von Session States (brauchts Du dringend, wenn Du einen Load Balancer benutzt) uvm.

>>Gibt es möglicherweise Probleme?

Gute Frage! Kann ich dir leider nicht beantworten, da ich z.B. nicht weis, was Du mit "Leistungsintensiven Prozessen" meinst.

Schöne GRüße

Oliver

Answer 2

Hallo,

 

Clouds hatte ich bereits im Sinn, kann ich allerdings aus etlichen Gründen nicht einsetzen. Die Datenhaltung übernimmt die "grüne Schicht" (MSSQL Server). Die Session-States bzw. Load Balancing wird von der "roten Schicht" übernommen. Load Balancing für die Backend-UI an sich realisiere ich wahrscheinlich mit DNS. Mit Leistungsintensiven Prozessen meine ich

1. die Datenhaltung der Benutzer per MSSQL

2. die Speicherung der dynamisch generierten Nutzerseiten

3. Die Behandlung von Speicher/CPU-Intensiven Nutzeroperationen

 

Es soll noch gar nicht so in die Details gehen, sondern erst mal nur um das Serverkonzept und die Interaktion der Anwendungen an sich.

 

Grüße

Answer 3

Hallo .net-tier,

>>Clouds hatte ich bereits im Sinn, kann ich allerdings aus etlichen Gründen nicht einsetzen.

Als Moderator des Windows Azure Forum hier auf MSDN würden mich deine Gründe echt interessieren.

>>Die Datenhaltung übernimmt die "grüne Schicht" (MSSQL Server).

Die Daten über deine Benutzer brauchst Du aber schon auf der Produktstartseite für den Anmeldeprozess (bzw. Registrierung neuer Benutzer). Willst Du den Vorgang jedesmal komplett durchreichen?

>>Die Session-States bzw. Load Balancing wird von der "roten Schicht" übernommen.

Wie willst Du die Session State Verwaltung lösen? Ein Load Balancer hat den Nachteil, dass er dir bei einer möglichen Unterbrechung der Session einen anderen Webserver zuordnen kann und sehr wahrscheinlich auch zuordnen wird.

Ich möchte echt nicht dein Architekturkonzept kritisieren, aber im Moment sehe ich noch Schwachpunkte.

Schöne Grüße

Oliver

Answer 4

Ich glaube, ich habe mich etwas unverständlich ausgedrückt.

Das was zwischen dem "Worker" und der UI passiert, sollte kein "echtes" Load Balancing sein, sondern ein paar Einfache Fallunterscheidungen, die Codeseitig durchgeführt werden. Die UI kennt einfach nur alle Worker-Server, und weiß, welche Funktionen dort ansprechbar sind. Die Webservices der "Worker" geben auf Anfrage der UI zurück, inwiefern sie nach vorgegebener Kalkulation noch Benutzer aufnehmen können. Die UI klappert alle Server ab und sucht dann den am wenigsten "belegten" aus. Zum Beispiel wird bei Anmeldung eines neuen Benutzers der Server mit den wenigsten Usern gewählt.

Azure ist vor allem eines: Für mein Modell zu teuer. Zeit / Nutzungsbasierte Abrechnung ist für das Projekt wohl das kostenintensivste, was ich machen könnte.

Der Anmeldeprozess findet auch auf einer separaten Seite des Backends statt. Die vorgeschaltete Seite ist nur die Öffentliche Website und auch die einzige mit "echtem" Load Balancing.