Was bedeutet "Skalierbarkeit" genau?

[Andreas]

Hallo!

Vor allem im Zusammenhang mit Servern höre ich oft das Schlagwort "gute Skalierbarkeit" als Vorteil einer Lösung. Aber ich kann mir nicht recht vorstellen was das heißt! Also nicht sowas wie irgendeine Bandbreite, die steht ja immer voll zur Verfügung, aber Skalierbarkeit sollte ja bedeuten das man die Hardware auf steigende Anforderungen einfach anpassen kann, würde ich jetzt mal interpretieren. Oder was heißt das genau? Ich kann mir darunter einfach nichts vorstellen, auch nicht was es technisch für einen Sinn macht diese vorerst künstlich zu beschränken.
Für Software verstehe ich das noch weniger, was soll da "Skalierbar" sein?

Viele Grüße
Andreas

[Cruz]

Hallo Andreas,

du hast schon den richtigen Ansatz gehabt. Skalierbarkeit bedeutet, dass die Hardware bzw. Software wachsenden Anforderungen, sprich höhere Anzahl von Usern, frequentiertere Anfragen und größere Menge an Daten standhält, oder sich problemlos upgraden lässt.

Ansonsten ist Skalierbarkeit genau wie Plattformunabhängigkeit ein Marketing-Schlagwort, wovon die Entscheider nicht wissen, was sie genau heißen, sie aber unbedingt auf der Verpackung lesen wollen. :)

Gruß,
Cruz

Hallo!

Vor allem im Zusammenhang mit Servern höre ich oft das Schlagwort "gute Skalierbarkeit" als Vorteil einer Lösung. Aber ich kann mir nicht recht vorstellen was das heißt! Also nicht sowas wie irgendeine Bandbreite, die steht ja immer voll zur Verfügung, aber Skalierbarkeit sollte ja bedeuten das man die Hardware auf steigende Anforderungen einfach anpassen kann, würde ich jetzt mal interpretieren. Oder was heißt das genau? Ich kann mir darunter einfach nichts vorstellen, auch nicht was es technisch für einen Sinn macht diese vorerst künstlich zu beschränken.
Für Software verstehe ich das noch weniger, was soll da "Skalierbar" sein?

Viele Grüße
Andreas

[Andreas]

Hallo!

du hast schon den richtigen Ansatz gehabt. Skalierbarkeit bedeutet, dass die Hardware bzw. Software wachsenden Anforderungen, sprich höhere Anzahl von Usern, frequentiertere Anfragen und größere Menge an Daten standhält, oder sich problemlos upgraden lässt.

Aber wie sieht das in der Praxis aus? OK, Load-Balancing ist eins, Cluster ein anders, und Netzwerk-Banbreite noch ein anderes!

Ansonsten ist Skalierbarkeit genau wie Plattformunabhängigkeit ein Marketing-Schlagwort, wovon die Entscheider nicht wissen, was sie genau heißen, sie aber unbedingt auf der Verpackung lesen wollen. :)

OK, aber Plattformfähigkeit ist doch nicht bloß eine Phrase?! z.B. ein Java-Programm, oder eine Intranet... das ist doch recht Plattformunabhängig, MS Office eher nicht, oder wie meinst Du das?

Viele Grüße
Andreas

[Cheatah]

Hi,

Aber wie sieht das in der Praxis aus?

leider nicht so leicht, wie man es gerne hätte. Man muss sich bei allem, was man entwickelt, stets überlegen, wie die Skalierung von statten gehen soll, wann man auf Probleme treffen könnte (insbesondere was die Verteilung von Daten anbelangt), und wie man diese löst.

OK, Load-Balancing ist eins,

Dazu ein relativ triviales :-) Das Problem hierbei ist vor allem, die Daten auf alle gebalanceten Systeme verteilen zu müssen. Solange der Server nur lesend eingesetzt wird, ist das relativ unkritisch; aber bei Schreibzugriffen gibt es schon die Schwierigkeit, dass beim ersten Request auf Rechner A geschrieben wird, beim nächsten Request die Daten aber schon auf Rechner B vorliegen müssen - die Lösung ist hier oft ein gemountetes Filesystem, welches aber seinerseits wieder kaum skalierbar ist. Nun beginnt man, sich Caching-Mechanismen zu überlegen usw... und wie gesagt, Loadbalancing ist eines der leichtesten Themen ;-)

OK, aber Plattformfähigkeit ist doch nicht bloß eine Phrase?! z.B. ein Java-Programm,

Peng, genau das richtige Stichwort. Java ist zwar wunderbar plattformunabhängig, d.h. ein Java-Programm läuft überall dort, wo man eine VM starten kann, aber trotzdem ist es von Plattform zu Plattform unterschiedlich. Als Beispiel sei nur erwähnt, dass Java auf dem Macintosh perfekt funktioniert, solange man nicht den IE mit Java installiert - dann werden nämlich einige Funktionen "geopfert", um den speziellen MS-Funktionen Platz zu bieten, die aber leider nicht so funktionieren, wie sie es sollten... und schon ist auf dem Mac Java praktisch nicht mehr einsetzbar. Dazu kommt, dass nicht jede einzelne Klasse wirklich plattformunabhängig programmiert wurde (Unterschied Theorie und Praxis) - so werden Grafikkonvertierungen, die z.B. unter Windows funktionieren, unter Linux in die Hose gehen oder umgekehrt, weil irgendwelche tiefliegenden Systemroutinen eingesetzt werden, die auf dem anderen System entweder nicht vorliegen oder anders arbeiten.

_Nichts_ ist wirklich plattformunabhängig. Ein Programm reagiert auf unterschiedlichen Plattformen höchstens hinreichend ähnlich.

oder eine Intranet...

Ein Intranet ist ein lokaler Ast des Internets. Ist das Internet plattformunabhängig? Ja und nein. Einerseits kann man mit (fast... der C-64 scheidet aus *g*) jeder Plattform ins Internet gehen, andererseits hängt die Nutzbarkeit vollkommen von der Site-Gestaltung ab. Wenn Active-X-Controls eingesetzt werden, scheidet ein Browser unter Linux aus.

Cheatah

[Andreas]

Hallo!

OK, Load-Balancing ist eins,

Das Problem hierbei ist vor allem, die Daten auf alle gebalanceten Systeme verteilen zu müssen. Solange der Server nur lesend eingesetzt wird, ist das relativ unkritisch; aber bei Schreibzugriffen gibt es schon die Schwierigkeit, dass beim ersten Request auf Rechner A geschrieben wird, beim nächsten Request die Daten aber schon auf Rechner B vorliegen müssen - die Lösung ist hier oft ein gemountetes Filesystem, welches aber seinerseits wieder kaum skalierbar ist. Nun beginnt man, sich Caching-Mechanismen zu überlegen usw...

Ich habe ein ähnliches Problem, würde ich jetzt nicht als Skalierbarkeits-Problem bezeichnen, aber die probleme sind demnnoch ähnlich:
Ich will eine Datenbank mit gleichem Datenbestand an 3 Standorten haben, wobei an jedem Standort Daten ergänzt/verändert werden können.
Da ich MySQL verwende und leider an einem Standort nicht genügend Rechte habe, kann ich nicht den Snyc-Mechanismus der in MySQL implementiert ist verwenden, wobei der wahrscheinlich auch nur mit 2 Standorten funktioniert hätte.
Da sich Daten gleichzeitig an verschiedenen Standorten ändern können kann ich nicht einfach genau dieselben Tabellen haben und die untereinander abgleichen, ich brauche zu jedem Datensatz eine MasterID und eine ClientID, um dann zu sehen ob sich ein Datensatz verändert hat, neu hinzugekommen ist... und sich dabei dann wirklich nichts überschneidet. Aber dadurch wird der Datenaustausch SEHR kompliziert, da ich Daten nicht einfach kopieren kann(mysqldump..., binlog), denn ich muß die Daten ja verändern, wenn es beispielsweise noch keine MasterID gibt!
Das ganze ist wirklich kompliziert, und alle haben mir bis jetzt gesagt "laß es..." aber ich würde es doch ganz gerne mal hinbekommen, über denselben Datenbastand an 3 oder mehr Standorten(1 Master, 2 oder mehr Clients) zu verfügen, obwohl an allen Stanbdorten gleichzeitig Einträge gemacht werden könne und Datensätze verändert werden können. Sicher, man muß für das Frontend Regeln definieren, das sich da möglichst keine Konflikte ergeben... genug abgeschweift, aber glaube mir das hat mich schon viele Haare gekostet ;-)

_Nichts_ ist wirklich plattformunabhängig. Ein Programm reagiert auf unterschiedlichen Plattformen höchstens hinreichend ähnlich.

oder eine Intranet...

Ein Intranet ist ein lokaler Ast des Internets. Ist das Internet plattformunabhängig? Ja und nein. Einerseits kann man mit (fast... der C-64 scheidet aus *g*) jeder Plattform ins Internet gehen, andererseits hängt die Nutzbarkeit vollkommen von der Site-Gestaltung ab. Wenn Active-X-Controls eingesetzt werden, scheidet ein Browser unter Linux aus.

Wenn Du sagst es gibt keine "Plattformunabhängigkeit", dann sage ich dass wenn man diese Unabhängigkeit dennoch anstrebt, man sehr wohl darauf achten wird/sollte, das man keine bekanntermaßen inkompatiblen Techniken einsetzt!

Vielen Dank für Deine Antworten, hast mir sehr geholfen!

Viele Grüße
Andreas

[Cheatah]

Hi,

Ich will eine Datenbank mit gleichem Datenbestand an 3 Standorten haben, wobei an jedem Standort Daten ergänzt/verändert werden können.

schwierig. Ideal wäre eine Aktualisierung aller Datenbestände in (annähernd) Echtzeit.

Da ich MySQL verwende und leider an einem Standort nicht genügend Rechte habe,

Du hast eine große Macht, die Du vergisst: Du kannst den Provider wechseln. Wenn er Dir nicht genügend Rechte gibt, verlasse ihn einfach! Alles andere wäre Unsinn - Du legst Dir selbst Steine in den Weg, weil jemand anders auf stur stellt. Frage Deinen Provider, unter welchen (auch monitären) Bedingungen er Dir die von Dir benötigten Berechtigungen gibt.

kann ich nicht den Snyc-Mechanismus der in MySQL implementiert ist verwenden, wobei der wahrscheinlich auch nur mit 2 Standorten funktioniert hätte.

Binäre Bäume funktionieren auch mit drei Blättern, also geht eine Synchronisation dreier Quellen, deren Mechanismus für zwei Quellen ausgelegt ist, ebenfalls.

Da sich Daten gleichzeitig an verschiedenen Standorten ändern können kann ich nicht einfach genau dieselben Tabellen haben und die untereinander abgleichen, ich brauche zu jedem Datensatz eine MasterID und eine ClientID, um dann zu sehen ob sich ein Datensatz verändert hat, neu hinzugekommen ist... und sich dabei dann wirklich nichts überschneidet.

Dabei ist es sicher nicht ganz unerheblich, dass MySQL keine Foreign Keys beherrscht. Möglicherweise ist dieses DBMS auch eine ungünstige Wahl der Technik.

Aber dadurch wird der Datenaustausch SEHR kompliziert, da ich Daten nicht einfach kopieren kann(mysqldump..., binlog), denn ich muß die Daten ja verändern, wenn es beispielsweise noch keine MasterID gibt!

Niemand hat gesagt, dass es leicht ist :-)

Das ganze ist wirklich kompliziert, und alle haben mir bis jetzt gesagt "laß es..."

Nö. Durchdenke es genau - und überdenke auch jedwede bisher getroffene Entscheidung. Was Dich behindert, war offenbar ein Fehler, dessen Korrektur Du in Erwägung ziehen solltest.

aber ich würde es doch ganz gerne mal hinbekommen, über denselben Datenbastand an 3 oder mehr Standorten(1 Master, 2 oder mehr Clients)

Hm, ist "Client" wirklich der richtige Begriff? Wenn ich Dich richtig verstehe, wäre "Mirror" passender.

zu verfügen, obwohl an allen Stanbdorten gleichzeitig Einträge gemacht werden könne und Datensätze verändert werden können.

Dann sind alle drei Master. Du musst Dir einen Plan jeden denkbaren Unterschieds zwischen zwei Datenbeständen machen (auf A hinzugefügt, auf B nicht vorhanden; auf A gelöscht, auf B verändert; ...), und wie Du jeweils drauf reagieren möchtest. Eventuell möchtest Du auch einzelne Datensätze (Datensatzgruppen) an einen Master binden und ihn nur dort verändern lassen.

Sicher, man muß für das Frontend Regeln definieren, das sich da möglichst keine Konflikte ergeben... genug abgeschweift, aber glaube mir das hat mich schon viele Haare gekostet ;-)

Willkommen in der wunderbaren Welt der Computer ;-)

_Nichts_ ist wirklich plattformunabhängig.

Wenn Du sagst es gibt keine "Plattformunabhängigkeit",

Keine wirkliche - ganz einfach deswegen, weil es in der Praxis schwer umzusetzen ist. Bleiben wir bei Java: Die Sprache an sich und ihre Umsetzung ist plattformunabhängig. "Theoretisch" könnte ein Java-Programm wirklich überall identisch laufen. Allerdings wird dazu eine VM benötigt - die speziell für die Plattform entwickelt wurde, also für sich genommen das Gegenteil von plattformunabhängig ist. Dadurch resultieren im Detail natürlich Unterschiede.

dann sage ich dass wenn man diese Unabhängigkeit dennoch anstrebt,

Nun, wenn ein Programm auf jedem Rechner läuft, auf dem man es startet, dann ist das doch zweifellos gut, oder?

man sehr wohl darauf achten wird/sollte, das man keine bekanntermaßen inkompatiblen Techniken einsetzt!

Du redest von Standards, also z.B. RFCs, ISO-Normen usw. Wenn sich alle daran halten, wird der Umgang mit anderen Techniken sehr einfach - weil genau definiert ist, wie das Maß der Kompatibilität auszusehen hat. Somit ist Inkompatibilität kein Problem mehr, weil sie durch die Standards erschlagen wird. Das hat dann aber mit der Plattform schon nichts mehr zu tun :-)

Cheatah

[Andreas]

Hallo Cheatah!

Hätte gar nicht gedacht das Du darauf antwortest ;-)

Ich will eine Datenbank mit gleichem Datenbestand an 3 Standorten haben, wobei an jedem Standort Daten ergänzt/verändert werden können.

schwierig. Ideal wäre eine Aktualisierung aller Datenbestände in (annähernd) Echtzeit.

^^^^^^^^^^^
Das ist das Problem, man kann sich auf den Kopf stellen, aber man wird nicht verhindern können, das sich auf einem der Systeme etwas verändert hat während man z.B. einen neuen Datensatz angelegt hat, und wenn 1/10 Sekunde zuvor an einem anderen Standort ebenfalls ein Datensatz angelegt wurde, haben - bei exakt gleichen Datenbeständen - diese beiden Datensätze dieselbe ID aber andere Daten - wenn zwischendurch nicht abgeglichen wurde. Ich finde es ist sicherer auf MasterID und ClinetID zurückzugreifen, da wird nur von einer Master-DB die MasterIDs verteilt, so ist sichergestellt das es zu keiner Inkonsistenz der Daten kommt!

Da ich MySQL verwende und leider an einem Standort nicht genügend Rechte habe,

Du hast eine große Macht, die Du vergisst: Du kannst den Provider wechseln. Wenn er Dir nicht genügend Rechte gibt, verlasse ihn einfach! Alles andere wäre Unsinn - Du legst Dir selbst Steine in den Weg, weil jemand anders auf stur stellt. Frage Deinen Provider, unter welchen (auch monitären) Bedingungen er Dir die von Dir benötigten Berechtigungen gibt.

Das habe ich vor kurzem schon gemacht, bis auf die ein oder andere Beschränkung mit Cronjobs bin ich da eigentlich hochzufrieden. Wenn ich alle Möglichkeiten haben will brauche ich einen eigenen Server, den ich dann selbst warten... müßte! Und das hat auch seinen Sinn das der MySQL-Port geschlossen ist - Sicherheit! Aber das Logging könnte ich da ja auch nicht machen, da nicht 1 Server pro Kunde! Aber selbst wenn ich das alles hätte, der MySQL Mechanismus ist ein Replikationsmechanismus, das heißt aber das nur auf dem MasterServer einträge gemacht/geändert werden können, die andern Datebanken sind ledigliche "Kopien" die man nur auslesen kann.

wäre dann aber trotzdem ein Beispiel _für_ Skalierbarkeit, oder?<<<

Dabei ist es sicher nicht ganz unerheblich, dass MySQL keine Foreign Keys beherrscht. Möglicherweise ist dieses DBMS auch eine ungünstige Wahl der Technik.

Das kann schon sein, aber was würden mir Foreign Keys hier bringen?

Nö. Durchdenke es genau - und überdenke auch jedwede bisher getroffene Entscheidung. Was Dich behindert, war offenbar ein Fehler, dessen Korrektur Du in Erwägung ziehen solltest.

Meinst Du den Provider? Wie gesagt, durch eine Wechsel würd eich im Prinzip nichts gewinnen, außerdem ist mir kein Provider bekannt der ein Hostingpaket mit so weitreichenden Rechten(z.B. Neustarten des MySQL-Servers) vertreibt!

Hm, ist "Client" wirklich der richtige Begriff? Wenn ich Dich richtig verstehe, wäre "Mirror" passender.

Eben nicht! Der Mirror ist im Prinzip eine Replikation eines Masters, oder? Was ich mache ist z.B. folgendes:

Ein Shop mit 3 örtlich voneinander getrennten Standorten:
1. Homepage/online-Shop beim Provider(autom. Speicherung v. Bestellungen in DB)
2. Verkaufsfläche (manuelle Aufnahme/Änderung von Bestellungen und Speicherung in DB)
3. Verwaltung (manuelle Aufnahme/Änderung von Bestellungen und Speicherung in DB)

Jeder Standort verfügt über eine eigene MySQL Datenbank(im jeweils eigenen LAN). Die Datenbestände sollen überall gleich sein. Da die DB beim Provider immer verfügbar ist würde ich diese als Master-DB verwenden, über die sich die beiden anderen Standorte(Client-DBs) abgleichen.

Wenn jetzt z.B. in der Verkaufsfläche eine Bestellung manuell eingegeben wird, und gleichzeitig im Online-Shop eine Bestellung eingeht, kommen sich die IDs beim nächsten Abgleich in die Quere. Daher hatte ich mir gedacht den Datensätzen in den Clients eigene IDs zu geben, und die MasterID erst beim Abgleich von der Master-DB vergeben zu lassen.
Dann muß ich alle Tabellen mit MySQL-Timestamps versehen und in einer extra Tabelle den letzten Synchronisations-Zeitpunkt speichern, um die Datensätze die nach der letzten Synchronisation geändert worden sind zu ermitteln.

In einem Script muß ich dann alle Datensätze die neuer als der letzte Synczeitpunkt sind per Select abfragen, die vielleicht direkt als inserts/updates/deletes speichern, dann mit Hilfe von PSCP zum Server übertragen und mit Hilfe von Plink dort ein Script starten, welches ebenso alle neuen Daten ausliest und dann die zuvor übertragenen querys ausführt. Am Ende muß ich ebenfalls die inserts/updates/deletes für den Client erzeugen und als Datei speichern, und mit PSCP die Datei runterladen und schließlich beim Client die inserts/updates/deletes ausführen.

Bleibt nur noch die Frage wie diese Synchronisation in Gang gesetzt wird, evtl. durch einen Cronjob oder beim Starten/Herunterfahren des Programms, am besten wäre natürlich bei jeder Änderung, aber das weiß ich noch nicht... mal schaun.

So sieht meine Idee zur Zeit aus, wobei ich so weit noch nicht bin, zur Zeit läuft das alles noch einfach vom Master-Server aus, der einfach eine Verbindung zu beiden DBs herstellt und alle Querys unverschlüsselt quer durchs Netz schickt... nicht wirklich gut.

Dann sind alle drei Master. Du musst Dir einen Plan jeden denkbaren Unterschieds zwischen zwei Datenbeständen machen (auf A hinzugefügt, auf B nicht vorhanden; auf A gelöscht, auf B verändert; ...), und wie Du jeweils drauf reagieren möchtest. Eventuell möchtest Du auch einzelne Datensätze (Datensatzgruppen) an einen Master binden und ihn nur dort verändern lassen.

Wie soll ich Datensatzgruppen definieren? Und dann anders behandlen, kann ich mir irgendwie nicht vorstellen?!
Der Begriff Master der kommt bei mir auch nur daher, dass sich die anderen DBs über diese abgleichen und da diese auch die MasterIDs vergibt.

Willkommen in der wunderbaren Welt der Computer ;-)

Jajaja, das wird irgendwie immer "schlimmer"!

Und Danke nochmal für Deine sehr hilfreichen Antworten!

Viele Grüße
Andreas

[Henryk Plötz]

Moin,

Einerseits kann man mit (fast... der C-64 scheidet aus *g*) jeder Plattform ins Internet gehen

Ja, das glaubst du vielleicht: http://slashdot.org/articles/02/04/15/043205.shtml.

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Cheatah]

Hi,

Vor allem im Zusammenhang mit Servern höre ich oft das Schlagwort "gute Skalierbarkeit" als Vorteil einer Lösung. Aber ich kann mir nicht recht vorstellen was das heißt!

wenn Du den Begriff oft im Zusammenhang mit Servern liest, bedeutet das vermutlich, dass Du Dich mit diesen Systemen mehr beschäftigst als mit anderen :-)

Jedes System, sei es nun ein Webserver, eine Datenbank, der Google-Spider zur Reindizierung der Seiten oder etwas, das nicht mal was mit dem Internet zu tun haben mag, stößt bei steigender Datenmasse oder -komplexität irgendwann an seine Leistungsgrenze. Nur die Festplatten zu vergrößern, den Arbeitsspeicher zu erhöhen oder den Prozessor zu beschleunigen reicht gewöhnlich nicht aus, um das System weiterarbeiten zu lassen. Die Lösung lautet: aus eins mach zwei. Statt einem Webserver werden zwei über einen Loadbalancer zusammengeschaltet, zur Datenbank gesellt sich eine zweite, und Google hat IIRC mittlerweile sechstausend Rechner stehen - alle gleichwertig über http://www.google.de/com/wasimmer erreichbar. Die Systeme wurden skaliert.

Also nicht sowas wie irgendeine Bandbreite, die steht ja immer voll zur Verfügung,

Nun, darüber kann man streiten :-)

Cheatah

[Andreas]

Hallo!

wenn Du den Begriff oft im Zusammenhang mit Servern liest, bedeutet das vermutlich, dass Du Dich mit diesen Systemen mehr beschäftigst als mit anderen :-)

Kann schon sein, jedenfalls fällt das auch insgesamt auf!

Jedes System, sei es nun ein Webserver, eine Datenbank, der Google-Spider zur Reindizierung der Seiten oder etwas, das nicht mal was mit dem Internet zu tun haben mag, stößt bei steigender Datenmasse oder -komplexität irgendwann an seine Leistungsgrenze. Nur die Festplatten zu vergrößern, den Arbeitsspeicher zu erhöhen oder den Prozessor zu beschleunigen reicht gewöhnlich nicht aus, um das System weiterarbeiten zu lassen. Die Lösung lautet: aus eins mach zwei. Statt einem Webserver werden zwei über einen Loadbalancer zusammengeschaltet, zur Datenbank gesellt sich eine zweite, und Google hat IIRC mittlerweile sechstausend Rechner stehen - alle gleichwertig über http://www.google.de/com/wasimmer erreichbar. Die Systeme wurden skaliert.

Ja gut. Also ist Load-Balancing eine Form der Skalierbarkeit. Aber das kommt mir so komplizier vor, so wie sich das oft anhört ist müßte das einfach so funktionieren das Du einen "Regler hochschiebst" oder sowas. Impliziert Skalierbarkeit also immer, das bei Bedarf mehr Systeme, ob jetzt Webserver... oder Maschinen... zusammengeschaltet werden ud sich die Arbeit teilen und so ingesamt mehr Leisten können, oder? Was gibt es noch für Beispiele für Skalierbarkeit?

Also nicht sowas wie irgendeine Bandbreite, die steht ja immer voll zur Verfügung,

Nun, darüber kann man streiten :-)

OK, es gibt ja auch hier Lösungen die Skalierbar sind, ich glaube von QXL, indem man z.B. eine 1Mbit Standleitung bekommt, definitiv nur diese nutzen kann und bezahlt, aber es kann einfach in eine 4Mbit umgewandelt werden, ohne neue Hardware... wäre dann vielleicht eher ein Beispiel _für_ Skalierbarkeit ;-)

Jedenfalls vielen Dank für die Info!

Grüße
Andreas

[Cheatah]

Hi,

Also ist Load-Balancing eine Form der Skalierbarkeit.

ja, und zwar eine der einfachsten.

Aber das kommt mir so komplizier vor, so wie sich das oft anhört ist müßte das einfach so funktionieren das Du einen "Regler hochschiebst" oder sowas.

Leider nicht. Denk beispielsweise an Systeme, die von _einer_ (veränderlichen) Datenquelle abhängig sind, und sei es nur eine Konfigurationsdatei. Wenn man nun auf sieben Systeme skaliert, braucht man entweder diese Datei entsprechend oft (und muss sie alle separat aktualisieren), oder man muss sich etwas überlegen. Denk an eine Datenbank, die ihre Daten natürlich nur einmalig halten möchte, aber "irgendwie" mit mehreren Systemen darauf zugreifen soll. Denk an komplexe Berechnungen, die sich eigentlich nicht verteilen lassen: auch Dualprozessoren sind eine Form der Skalierung, Seti@home dito.

Skalierung ist, _das_ Programm (egal um was es gerade geht) auf mehreren Rechnern so laufen zu lassen, dass es immer noch wie ein Programm wirkt. Kannst Du Dir vorstellen, dies mit - sagen wir - Word zu tun?

Impliziert Skalierbarkeit also immer, das bei Bedarf mehr Systeme, ob jetzt Webserver... oder Maschinen... zusammengeschaltet werden ud sich die Arbeit teilen und so ingesamt mehr Leisten können, oder?

Nein, das impliziert Skalierbarkeit nicht, das _ist_ Skalierbarkeit :-)

OK, es gibt ja auch hier Lösungen die Skalierbar sind, ich glaube von QXL, indem man z.B. eine 1Mbit Standleitung bekommt, definitiv nur diese nutzen kann und bezahlt, aber es kann einfach in eine 4Mbit umgewandelt werden, ohne neue Hardware... wäre dann vielleicht eher ein Beispiel _für_ Skalierbarkeit ;-)

Oder für bewusste Einschränkung der auf einem System verfügbaren Leistung ;-)

Cheatah

[Felix Rabe]

Hallo!

Hallo.

Hab gerade (sehr) kürzlich etwas in einem Leserbrief von Linux Weekly News gelesen.  (Die übrigens wegen unerwartet hoher Spenden darüber nachdenken, weiterzumachen - sofern überhaupt jemand von der tragischen "Story" erfahren hat...)

--> http://lwn.net/Articles/5061/

cu,
Felix

[Andreas]

Hallo!

--> http://lwn.net/Articles/5061/

interessant. Also ist Linux nicht skalierbar, Solaris schon? Habe das nicht so 100%ig verstanden, halt nur soviel das Linux auf einem 64bit Prozessor nicht viel schneller wird und auf Mehrprozessorsystemen gar nicht läuft, da es dafür nicht gebaut wurde, aber ich kann mich auch irren ;-)

Grüße
Andreas

PS: das stand im Kommentar, nicht im Artikel!

[Henryk Plötz]

Moin,

Ich kann mir darunter einfach nichts vorstellen, auch nicht was es technisch für einen Sinn macht diese vorerst künstlich zu beschränken.
Für Software verstehe ich das noch weniger, was soll da "Skalierbar" sein?

Das hat nichts mit künstlich beschränken zu tun, sondern eher mit prinzipiellen Schranken.

Beispiel: Das Filesharing-Netz Gnutella. Suchanfragen und Antworten werden zwischen Servents direkt ausgetauscht. Um zu Verhindern, dass Anfragen ewig rumkurven, kriegen alle Pakete eine Time-to-Live, also eine maximale Anzahl von Zwischenstationen die sie passieren können, bevor sie gelöscht werden. Daraus ergibt sich, dass ein Servent eine bestimmte maximale Anzahl an anderen Servents sehen kann. (Bin mir nicht sicher, aber das müsste in der Gegend von (Durschnittliche Anzahl der direkten Verbindungen zu anderen Servents) hoch TTL liegen.)
Um diesen Sichtbereich zu erweitern, müsste man jetzt die TTL hochdrehen, bekommt dann aber Probleme, weil a) die Antwort-Zeit steigt und b) der durschnittliche Netzwerkverkehr der nur mit diesen Metadaten verschwendet wird (also noch nicht zum Dateienübertragen benutzt werden kann) ebenfalls stark steigt. Oder man könnte die Anzahl der Verbindungen zu anderen Servents erhöhen, bekommt dann aber Probleme, weil der Netzwerkverkehr für Metadaten dadurch auch steigt.
Man sieht: Gnutella skaliert schlecht auf viele Teilnehmer mit langsamen Leitungen.

Das Gegenbeispiel wäre Fast-Track: Es gibt eine Anzahl an SuperNodes die aufgrund ihrer überdurchschnittlich schnellen Internetanbindung und verfügbaren Rechenkapazität ausgewählt werden und die sind untereinander alle verbunden. Dann gibt es noch Nodes, die jeweils eine Verbindung zu einer oder mehreren SuperNodes aufrechterhalten. Die Supernodes wissen, welche Dateien die mit ihnen verbundenen Nodes bereitstellen und bearbeiten alle Suchanfragen unter sich. Da sie so dicke Leitungen haben, ist es kein Problem, dass dort viele Metadaten umherflitzen. Die Internetanbindungen jeder einzelnen Node wird nur mit von dieser Node direkt gestellen Suchanfragen und den Antworten darauf zusätzlich zum Dateiaustausch belastet. Sollten mehr Nodes in das Netzwerk kommen, werden halt mehr SuperNodes bestimmt.
Man sieht: Fast-Track skaliert wesentlich besser auf viele Teilnehmer mit langsamen Leitungen. Es müssen nur ein gewisser Prozentsatz der Teilnehmer auch besonders dicke Leitungen haben (und das ist eigentlich immer der Fall).

Ähnliche Probleme erwarten dich _immer_ wenn du irgendetwas verteilt erledigen musst. Es gibt einen bestimmten Aufwand den jedes Teilsystem relativ unabhängig von den anderen erledigen kann (die reinen Berechnungen zum Beispiel) und es gibt einen Aufwand für die Kommunikation und Koordination der Teilsysteme, der dich der Erfüllung deiner Aufgabe nicht direkt näher bringt. Leider steigt letzterer Aufwand bei eigentlich allen Problemklassen deutlich schneller als linear, die insgesamt zur Verfügung stehende Kapazität steigt aber nur linear. Es gibt also immer einen Punkt, an dem das, was du durch Hinzufügen neuer Komponenten an Kapazität gewinnst, weniger ist, als das, was du durch dieses Hinzufügen an Kapazität verlierst. (Natürlich fügst du niemals Komponenten bis zu dieser Grenze hinzu. Wenn durch eine Vervierfachung der Kosten, die Kapazität nichtmal mehr verdoppelt wird, überlegt man sich schon, ob das noch Sinn macht.)

Was den nachträglichen Ausbau angeht, so skaliert ein System offensichtlich umso besser, je weiter der oben erwähnte böse Punkt vom aktuellen Ausbau entfernt ist.
Allgemein skaliert das System besser, wenn der Kommunikationsoverhead klein ist, die Kosten also nahezu linear mit der Kapazität steigen.

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Andreas]

Hallo!

Vielen Dank, ich glaube jetzt verstehe ich es etwas besser!

Grüße
Andreas

[molily]

Hallo, Henryk,

Beispiel: Das Filesharing-Netz Gnutella. [...] Man sieht: Gnutella skaliert schlecht auf viele Teilnehmer mit langsamen Leitungen.

Glücklicherweise ändert sich das: http://rfc-gnutella.sourceforge.net/Proposals/Ultrapeer/Ultrapeers.htm
Gnucleus unterstützt das prächtig, Bearshare und Limewire AFAIK auch. Dennoch muss ich 10-15 direkte Ultrapeer-Verbindungen aufrecht erhalten, um eine Handvoll Dateien zu finden. Fasttrack (Kazaa Lite) ist in dem Punkt ungeschlagen. (Mit anderen abenteuerlichen kommerziellen closed-source Filsharingdiensten beschäftige ich mich i.d.R. nicht. Audiogalaxy war zwar perfekt, aber ebenso nontransparent. Abgesehen davon hat man Millionen Nutzern Spyware untergejubelt.)
Ein gutes Beispiel ist Gnutella dennoch, vgl. "Why Gnutella Can't Scale. No, Really." http://www.darkridge.com/~jpr5/doc/gnutella.html.

Grüße,
Mathias