1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Cloud Computing: Was ist eigentlich…

Und wie ist am Ende die reale Geschwindigkeit?

  1. Thema

Neues Thema Ansicht wechseln


  1. Und wie ist am Ende die reale Geschwindigkeit?

    Autor: mustermensch 06.10.16 - 10:48

    Verglichen mit einer lokalen SSD zum Beispiel?
    Dazu findet man selten etwas wenn es um "Cloud" geht.

    Dabei ist die Latenz und Bandbreite ja durchaus auch mal wichtiger als einfach nur endlos viele Daten speichern zu können.

    Edit: Allgemein ist "skalierbar" ein Wort bei dem ich sehr vorsichtig geworden bin. Zu oft ist es gleichbedeutend mit startet schnarchlangsam, und bleibt auf dem gleichen Level schnarchlangsam bei mehr Daten und mehr Hardware.



    1 mal bearbeitet, zuletzt am 06.10.16 10:50 durch mustermensch.

  2. Re: Und wie ist am Ende die reale Geschwindigkeit?

    Autor: madkiss 06.10.16 - 10:56

    Die richtige wenn auch sehr unbefriedigende Antwort ist: "Kommt drauf an". Durchsatz kann man sich relativ leicht anhand der vorhandenen Hardware ausrechnen: Die Frage ist lediglich, welche Komponente der Flaschenhals ist. 10GbE lassen sich mit Ceph bei entsprechender Anzahl von Spindeln im Cluster und entsprechend großen Dateien, die im Object Store landen sollen, problemlos saturieren.

    Wenn ich mehr Netzwerk zur Verfügung habe, stehe ich möglicherweise irgnedwann beim Bus im Client an. Oder das Laufwerk im Client, auf dem ich speichern möchte, ist nicht schnell genug. Oder oder oder ...

    Latenz ist deutlich kniffliger. Hier bin ich nach unten hin auf jeden Fall durch die inhärente Latenz von Ethernet bzw. die der Netzwerkhardware gedeckelt. Drunter kommt man nur mit anderen Lösungen -- etwa InfiniBand -- das sich aber mit kaum einer SDS-Lösung aktuell sinnvoll nutzen lässt.

  3. Re: Und wie ist am Ende die reale Geschwindigkeit?

    Autor: mustermensch 06.10.16 - 11:13

    "Kommt drauf an" ist sicherlich korrekt aber wenig nützlich ;)
    Natürlich kommt es auf die Hardware an, in der Realität hat man davon aber nicht beliebig viel zur Verfügung sondern will aus dem was man hat (bzw. dem Geld das man hineinstecken darf) das beste machen.

    Wenn ich jetzt z.B. ein Blade-Center mit X Blades und 10GbE habe, und x Webanwendungen betreiben muss, fahre ich besser damit
    - A) Allen Speicher mit Ceph o.ä. zu einem großen zusammenzumatschen, einen Load-Balancer davorzuhängen und jeder Server kann dann jede Anfrage bedienen.
    - B) oder die Anwendungen auf die Server zu verteilen, jeder hat nur die jeweils relevanten Daten im lokalen Speicher.

    A hat sicherlich Vorzüge beim Management und der Ausfallsicherheit. Aber wenn damit bei gleicher Hardware nur noch z.B. 1/10 des Durchsatzes möglich sind wird man sich das vielleicht trotzdem 2x überlegen...



    1 mal bearbeitet, zuletzt am 06.10.16 11:14 durch mustermensch.

  4. Re: Und wie ist am Ende die reale Geschwindigkeit?

    Autor: kaymvoit 06.10.16 - 11:25

    Eigentlich beantwortet der Artikel Diene Frage schon am Anfang. Es geht um Dynamik. Wenn Du deine x-Webanwendungen unter Kontrolle hast und die Platten entsprechend planen kannst, ist das vermutlich ok. Wenn Du das nciht kannst, und sagen wir mal 50000 100GB-Backupspacepakete verkaufst, dann kannst Du entweder TATSÄCHLICH 5PB Speicher anschaffen und vermutlich zu 50% leerlaufen lassen, oder du erweiterst ihn dynamisch mit der Belegung durch Diene Kunden.

  5. Re: Und wie ist am Ende die reale Geschwindigkeit?

    Autor: olqs 06.10.16 - 11:29

    Eines kann man schonmal sagen:
    Blade Server als Ceph Knoten sind eher ungünstig, da du nur sehr wenige Spindeln dort einbauen kannst.

    Bei der derzeitigen hat man ohne Auslagerung des OSD Journals auf eine SSD nur der halbe Schreibperformance einer OSD verfügbar. Zuerst wird auf die Journal Partition geschrieben und dann von dort auf die Datenpartition. Bei Bluestore als OSD Backend, bisher noch sehr experimentell ist das zweimalige Schreiben nicht mehr nötig.
    Lesezugriffe profitieren vom Filesystemcache der Ceph Knoten und da kommt es halt auf das Zugriffmuster der Clients an.

  6. Re: Und wie ist am Ende die reale Geschwindigkeit?

    Autor: TheBro 06.10.16 - 11:58

    Zu dem Thema Performance, Latenzen und Optimierungen von Ceph gibt es einiges von CERN. Sehr interessantes Video:
    https://www.youtube.com/watch?v=OopRMUYiY5E

  7. Re: Und wie ist am Ende die reale Geschwindigkeit?

    Autor: Mathok 06.10.16 - 12:04

    Also ich hab zwei kleine Systeme mit jeweils 3 Ceph Servern und 18 OSD da kann man es zusammen fassen als Lesend super bei Schreibend schlecht (aber für den Einsatzzweck hier völlig ausreichen). Man merkt bei diesem kleinem System wirklich jede OSD/Platte die mehr im System ist.

    Da komme ich lesend in einer Windows Server 2012 VM auf Qemu-kvm auf ca. 850 MB/s lesend und schreibend auf 220 MB/s.

    Mit rados bench dem Ceph eigenen Benchmark Tool direkt ohne was dazwischen auf Lesend 1904 MB/s und Schreibend 241 (MB/sec).

    Die niedrige Schreibrate lässt sich einfach erklären da ich 2 Kopien plus das Original von jedem Objekt vorhalte habe ich nur 6 Platten die effektiv zum schreiben benutzt werden können.

  8. Re: Und wie ist am Ende die reale Geschwindigkeit?

    Autor: mustermensch 06.10.16 - 12:06

    kaymvoit schrieb:
    --------------------------------------------------------------------------------
    > Eigentlich beantwortet der Artikel Diene Frage schon am Anfang. Es geht um
    > Dynamik.

    Das ist schon klar, man muss trotzdem irgendwie beurteilen können ob die Dynamik einem etwas nützt oder Nebeneffekte mitbringt die das ganze für einen unbenutzbar oder zu teuer machen.

    So wie ein Elektroauto sicher ganz toll ist, aber man trotzdem ein Problem hat wenn man nunmal schnell von Flensburg nach München kommen muss.

    > Wenn Du das
    > nciht kannst, und sagen wir mal 50000 100GB-Backupspacepakete verkaufst,
    > dann kannst Du entweder TATSÄCHLICH 5PB Speicher anschaffen und vermutlich
    > zu 50% leerlaufen lassen, oder du erweiterst ihn dynamisch mit der Belegung
    > durch Diene Kunden.

    Das ist natürlich ein schönes Beispiel wo so etwas wie Ceph definitiv Sinn ergibt.
    So ein Backupdienst braucht ja einen zentral verwaltbaren redundaten Speicher. Wenn ich den auf X Einzelservern betreiben will müsste eine entsprechende Speicherverwaltung sonst in der Anwendung selber implementieren und hätte auch nichts gewonnen.

  9. Re: Und wie ist am Ende die reale Geschwindigkeit?

    Autor: grslbr 06.10.16 - 21:03

    Jo, danke für das Beispiel. Hat einen kaskadierenden Erleuchtungsschub verursacht.

    Nobody belongs anywhere, nobody exists on purpose,
    everybody's going to die. Come watch TV?

  10. Re: Und wie ist am Ende die reale Geschwindigkeit?

    Autor: amagol 07.10.16 - 20:54

    mustermensch schrieb:
    --------------------------------------------------------------------------------
    > Verglichen mit einer lokalen SSD zum Beispiel?
    > Dazu findet man selten etwas wenn es um "Cloud" geht.

    Die lokale SSD bring dir aber nur etwas wenn du weisst das die Daten genau auf dieser SSD sind und in diesem Rechner gebraucht werden. man kann zwar eine Menge Probleme so sharden dass nur lokale Daten benoertigt werden, aber bei komplexeren zusammenhaengen (Graph statt Tree) ist eine rein lokale loesung nicht mehr machbar. In dem moment beginnt ein verteilter ("Cloud") Storage seine Vorteile auszuspielen. Mit einer SOA kann man versuchen den Zeitpunkt herauszuzoegern, aber auch da wird es irgendwann schwierig.
    Es ist nicht so dass es nicht ohne Cloud ginge, aber in fast allen Faellen kommt man zu einem Punkt wo man sich sagt, haette ich damals doch lieber eine skalierbare Loesung gewaehlt ;)

    > Dabei ist die Latenz und Bandbreite ja durchaus auch mal wichtiger als
    > einfach nur endlos viele Daten speichern zu können.

    Kann sein, aber Netz ist relativ schnell, selbst verglichen mit lokalen Festplatten. 1ms zusaetzliche Latenz und ein Bandbreitenlimit von 10GB/s (pro Port) ist fuer viele Anwendungen akzeptabel.

    > Edit: Allgemein ist "skalierbar" ein Wort bei dem ich sehr vorsichtig
    > geworden bin. Zu oft ist es gleichbedeutend mit startet schnarchlangsam,
    > und bleibt auf dem gleichen Level schnarchlangsam bei mehr Daten und mehr
    > Hardware.

    Skalierbar heisst nicht schnell, das ist richtig. Aber es schliesst sich auch nicht aus.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Technische Informationsbibliothek (TIB), Hannover
  2. BEUMER Group, Beckum (Raum Münster, Dortmund, Bielefeld)
  3. Deutschland sicher im Netz e.V., Berlin
  4. KVJS - Kommunalverband für Jugend und Soziales Baden-Württemberg, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. ab 299,90€ Bestpreis auf Geizhals
  2. ab 74,71€ Bestpreis auf Geizhals
  3. mit 340,01€ Tiefpreis bei Geizhals


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mobilfunk: UMTS-Versteigerungstaktik wird mit Nobelpreis ausgezeichnet
Mobilfunk
UMTS-Versteigerungstaktik wird mit Nobelpreis ausgezeichnet

Sie haben Deutschland zum Mobilfunk-Entwicklungsland gemacht und wurden heute mit dem Nobelpreis ausgezeichnet: die Auktionstheorien von Paul R. Milgrom und Robert B. Wilson.
Ein IMHO von Frank Wunderlich-Pfeiffer

  1. Coronakrise Deutsche Urlaubsregionen verzeichnen starke Mobilfunknutzung
  2. LTE Telekom benennt weitere Gewinner von "Wir jagen Funklöcher"
  3. Mobilfunk Rufnummernportierung darf maximal 7 Euro kosten

Oneplus 8T im Test: Oneplus gutes Gesamtpaket kostet 600 Euro
Oneplus 8T im Test
Oneplus gutes Gesamtpaket kostet 600 Euro

Das Oneplus 8 wird durch das 8T abgelöst. Im Test überzeugen vor allem die Kamera und die Ladegeschwindigkeit. Ein 8T Pro gibt es 2020 nicht.
Ein Test von Tobias Költzsch

  1. Bloatware Oneplus installiert keine Facebook-Dienste mehr vor
  2. Smartphone Oneplus 8 und 8 Pro bekommen Android 11
  3. Mobile Neues Oneplus-Smartphone für 200 US-Dollar erwartet

IT-Jobs: Die schwierige Suche nach dem richtigen Arbeitgeber
IT-Jobs
Die schwierige Suche nach dem richtigen Arbeitgeber

Nur jeder zweite Arbeitnehmer ist mit seinem Arbeitgeber zufrieden. Das ist fatal, weil Unzufriedenheit krank macht. Deshalb sollte die Suche nach dem passenden Job nicht nur dem Zufall überlassen werden.
Von Peter Ilg

  1. Digitalisierung in Firmen Warum IT-Teams oft übergangen werden
  2. Jobs Unternehmen können offene IT-Stellen immer schwerer besetzen
  3. Gerichtsurteile Wann fristlose Kündigungen für IT-Mitarbeiter rechtens sind