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

Da klingelen doch alle Alarmglocken ...

Helft uns, die neuen Foren besser zu machen! Unsere kleine Umfrage dauert nur wenige Sekunden!
  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Da klingelen doch alle Alarmglocken ...

    Autor: Linuxschaden 30.03.16 - 12:28

    Virtuelle Switche, das kommt mir doch irgendwie bekannt vor ... ach ja, stimmt: hier hab ich das gelesen ... ist aber auch schon drei Jahre her.

    Virtualisierung in Verbindung mit Netzwerken halte ich für eine blöde Idee. Hardware ist billig, schnell, und funktioniert, Auf der anderen Seite wundert mich es nicht; IT-ler in jeder Richtung gehen dazu über, die heute zur Verfügung stehende Rechenleistung für Blödsinn zu verwenden, anstatt ordentlich zu skalieren. Allerdings: wem kann man dann so einen Blödsinn aufschwatzen? Das Zeug will schließlich verkauft werden, und der Käufer muss den Kauf rechtfertigen, auch wenn er's nicht versteht ...

    EDIT: Das wird ja noch immer besser. Da googelt man dem Autor hinterher und sieht dann, dass der "Team Lead OpenStack" bei der SysEleven GmbH macht. Deren Slogan ist: "Hosting. Skaliert."

    Mit Virtualisierung, ja klar ... hahaha.



    1 mal bearbeitet, zuletzt am 30.03.16 12:38 durch Linuxschaden.

  2. Re: Da klingelen doch alle Alarmglocken ...

    Autor: bernd71 30.03.16 - 12:47

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Virtuelle Switche, das kommt mir doch irgendwie bekannt vor ... ach ja,
    > stimmt: hier hab ich das gelesen ... ist aber auch schon drei Jahre her.
    >
    > Virtualisierung in Verbindung mit Netzwerken halte ich für eine blöde Idee.
    > Hardware ist billig, schnell, und funktioniert, Auf der anderen Seite
    > wundert mich es nicht; IT-ler in jeder Richtung gehen dazu über, die heute
    > zur Verfügung stehende Rechenleistung für Blödsinn zu verwenden, anstatt
    > ordentlich zu skalieren. Allerdings: wem kann man dann so einen Blödsinn
    > aufschwatzen? Das Zeug will schließlich verkauft werden, und der Käufer
    > muss den Kauf rechtfertigen, auch wenn er's nicht versteht ...
    >
    > EDIT: Das wird ja noch immer besser. Da googelt man dem Autor hinterher und
    > sieht dann, dass der "Team Lead OpenStack" bei der SysEleven GmbH macht.
    > Deren Slogan ist: "Hosting. Skaliert."
    >
    > Mit Virtualisierung, ja klar ... hahaha.

    Und welche Alarmglocke soll da schrillen? Auf deinen Lösungsansatz mit Hardware in Cloud- und Container-Umgebungen bin ich mal gespannt.

  3. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Nikolaus117 30.03.16 - 12:49

    Also die Netzwerkvirtualisierung als "blöde Idee" darzustellen zeigt von Unwissen.

    VLANs haben sich bewährt und sind nicht mehr wegzudenken.
    Das Problem das diese VLANs schnell zu komplex und übersichtlich wird.
    Der Aufwand bei der Konfiguration ist in großen Netzwerken immens.

    Es gibt aber auch tolle Lösungen die auf Standards aufbauen wie Shortest Path Bridging 802.1aq und inzwischen in den VLAN standard 802.1Q integriert.
    Damit ist STP, MSTP und mit Avaya Fabric Connect auch OSPF, PIM, BGP usw. unnötig.
    Heißt ein Protokoll für das Gesamte L2/L3 Netzwerk. Nie wieder eine Konfiguration im Kern oder den Verteilern. Nur noch am Edge und selbst das mit Attach, LLDP, ADAC und Extend Funktionen schon jetzt fast vollautomatisch.

    Schnell, Mandaten Trennung, Sicher, kein Ausfall mehr, kein Wartungsfenster nötig, Konfigurationsaufwand liegt bei großen (100+ Switche) Netzwerken noch bei 10% oder weniger.

    Ein paar Videos und Links die Interessant sind.
    https://youtu.be/lOYhr4W7W5s
    https://en.wikipedia.org/wiki/IEEE_802.1aq
    https://youtu.be/xeo_fDBKlrg

  4. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Linuxschaden 30.03.16 - 13:04

    bernd71 schrieb:
    --------------------------------------------------------------------------------
    > Und welche Alarmglocke soll da schrillen? Auf deinen Lösungsansatz mit
    > Hardware in Cloud- und Container-Umgebungen bin ich mal gespannt.

    Es lassen. Ist Blödsinn. Skaliert absolut furchtbar und am Ende wirft man entweder noch mehr und mehr Hardware auf die Probleme, oder man behilft sich mit übelen Zwischenlösungen.

    Cloud braucht keine Sau, Virtualisierung braucht keine Sau. Filehoster haben wir bereits zuhauf, und einen HTTP-Server aufzusetzen, um Zugriff auf Daten zu ermöglichen sollte kein Problem darstellen.

    Nikolaus117 schrieb:
    --------------------------------------------------------------------------------
    >VLANs haben sich bewährt und sind nicht mehr wegzudenken.

    VLAN != virtuelle Switche. VLANs sind, meines Wissens (zugegeben, ich habe Anwendungsentwicklung gelernt, die Stunden über Layer 1 und 2 sind da ein wenig kürzer geraten) - sind Teilnetze innerhalb eines LANs. Und komischerweise sind port-basierte VLANs auch bekannt für ihre Skalierbarkeit und Übersicht, na sowas ...

  5. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Stiffler 30.03.16 - 13:12

    bernd71 schrieb:
    --------------------------------------------------------------------------------
    > Linuxschaden schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Virtuelle Switche, das kommt mir doch irgendwie bekannt vor ... ach ja,
    > > stimmt: hier hab ich das gelesen ... ist aber auch schon drei Jahre her.
    > >
    > > Virtualisierung in Verbindung mit Netzwerken halte ich für eine blöde
    > Idee.
    > > Hardware ist billig, schnell, und funktioniert, Auf der anderen Seite
    > > wundert mich es nicht; IT-ler in jeder Richtung gehen dazu über, die
    > heute
    > > zur Verfügung stehende Rechenleistung für Blödsinn zu verwenden, anstatt
    > > ordentlich zu skalieren. Allerdings: wem kann man dann so einen Blödsinn
    > > aufschwatzen? Das Zeug will schließlich verkauft werden, und der Käufer
    > > muss den Kauf rechtfertigen, auch wenn er's nicht versteht ...
    > >
    > > EDIT: Das wird ja noch immer besser. Da googelt man dem Autor hinterher
    > und
    > > sieht dann, dass der "Team Lead OpenStack" bei der SysEleven GmbH macht.
    > > Deren Slogan ist: "Hosting. Skaliert."
    > >
    > > Mit Virtualisierung, ja klar ... hahaha.
    .. und ist das schlimm? - einer der sich mal auskennt und nicht nur klug schwatzt ...

    >
    > Und welche Alarmglocke soll da schrillen?
    Die, die auch schon die ganze Zeit bei der Virtualisierung schrillt ...
    .. für jeden Schayss wir mal schnell ne neue VM genommen. Früher
    musste man noch überlegen, das ist jetzt "überflüssig". Mit ein
    paar Mausklicks ist jetzt jedes Problem erledigt ...
    Leider sind die Kosten für die VM nicht mehr so transparent wie
    für eine eigene Hardware.
    "Virtuelle Hardeware" wird bei Projekten mit "EDA-Kosten" verrechnet ...
    Die VLANS usw werden explodieren, und bei ner Fehlersuche wird es interessant.

    Stiffler

  6. Re: Da klingelen doch alle Alarmglocken ...

    Autor: warten_auf_godot 30.03.16 - 13:26

    *abnick*

    als Diplom-Informatiker muss man sich hier bzgl. Artikeln / Kommentaren ohnehin regelmäßig mit Facepalm abstützen. Jahre nachdem auch das hinterletzte Unternehmen ihre IT auf VMware/UCS/NetApp oder Vergleichbares umgestellt hat und auch die Endbenutzer nicht mehr auf cloudbasierte Dienste verzichten können (Dropbox, Facebook, Twitter, ...) zu verlangen, Myriaden an Instanzen- die nur noch durch hohen Automatisierungsgrad gemanaged werden können !mittels Hardware zu verkabeln! zeugt von grenzenloser Naivität.

    Zumindest die Artikel sind etwas besser geworden, seitdem sie von Gastautoren aus der IT-Branche verfasst werden, die tatsächlich auch einen MINT-Abschluss haben.

    Aber ich kann meine Maschinenbau-Ingenieurs-Kollegen mittlerweile verstehen, wenn Detlef - der Autoschrauber in Kommentaren erklärt, dass er das neue Mercedes SL Modell in seiner Hinterhofgarage mittels EBay-Schweissgerät und Spachtelmasse ohnehin viel besser hinbekommen hätte.

  7. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Linuxschaden 30.03.16 - 13:28

    Stiffler schrieb:
    --------------------------------------------------------------------------------
    > .. und ist das schlimm? - einer der sich mal auskennt und nicht nur klug
    > schwatzt ...

    Schlimm? Lustig.

    Virtualisierung und Skalierbarkeit funktioniert nicht. Zumindest nicht, wenn wir dabei sind, ganze Netzwerke virtuell zu bauen. Bei VLANs sach ich nichts, die können immer noch auf echter Hardware laufen, anstatt da auch wieder ein virtuelles System zwischenzuschieben.

    > Mit ein paar Mausklicks ist jetzt jedes Problem erledigt ...

    Wäre ja auch nicht schlimm. Siehe VLANs - lassen sich eben in Harware konfigurieren. Notfalls auch mit einem Perl-Skriptchen.

    Oder virtuelle Hosts bei HTTP-Servern. Sach ich nichts gegen, das ergibt schon Sinn.

    Aber virtuelle Maschinen für Kunden, die sie sich selbst zusammenklicken sollen?

    Ich komme aus der Linux-Ecke. Dort haben wir ulimits, um die Resourcen von Nutzern zu beschränken, und dass diese nicht auf anderer Leute Daten zugreifen, das stellt der Kernel sicher (IP-Stack und Dateirechteverwaltung). Wozu brauch ich da eine virtuelle Maschine, warum muss ich das Netzwerk virtualisieren?

  8. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Linuxschaden 30.03.16 - 13:41

    warten_auf_godot schrieb:
    --------------------------------------------------------------------------------
    > Diplom-Informatiker

    OK, dann erklärbäre mir das mal. Ich habe noch kein (!) Unternehmen gesehen, welches "VMware/UCS/NetApp oder Vergleichbares" wirklich gebraucht hat. Mehrere Leute auf einen Server zu verfrachten haben wir bereits in den 80ern geschafft. Das ist doch keine Raketentechnologie.

    Und Dropbox, Facebook, Twitter lasse ich dir auch nicht durchgehen. Wie gut die skalieren, sieht man doch daran, wie viel Hardware die auf ihre Probleme werfen, genau das, was ich auch bereits erwähnt habe. Deine "Myridaten an Instanzen" kann ich sogar besser skalierend auf echten Maschinen verwalten.

    Einzig den Komfort für den Entanwender könnte ich dir gelten lassen. Aber sagen wir mal, wir machen mal sowas wie Dropbox, nur in ordentlich - dann würde ich dafür sorgen, dass es Programme gibt, die genau das gleiche machen. Daten von Nutzer zu Nutzer schieben, Hoch-, Runterladen ...

    > Aber ich kann meine Maschinenbau-Ingenieurs-Kollegen mittlerweile
    > verstehen, wenn Detlef - der Autoschrauber in Kommentaren erklärt, dass er
    > das neue Mercedes SL Modell in seiner Hinterhofgarage mittels
    > EBay-Schweissgerät und Spachtelmasse ohnehin viel besser hinbekommen hätte.

    Ich kann Detlef viel eher verstehen, wenn er sagt, dass die Steuerungsanlage, die die Mercedes SL Modelle baut, hervorragend funktioniert, und dass es keinen Grund gibt, das Bauen erst mal durch vier, fünf, sechs Schichten durchlaufen zu lassen, wodurch die Skalierbarkeit rapide abnimmt. Nochmal, Benutzerkontensteuerung haben wir in den
    80ern gemacht. Datentransfer haben wir in den 80ern gemacht.

    EDIT: Unreferenzierte Ziterung entfernt.



    1 mal bearbeitet, zuletzt am 30.03.16 13:53 durch Linuxschaden.

  9. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Psy2063 30.03.16 - 13:53

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Es lassen. Ist Blödsinn. Skaliert absolut furchtbar und am Ende wirft man
    > entweder noch mehr und mehr Hardware auf die Probleme, oder man behilft
    > sich mit übelen Zwischenlösungen.

    naja so pauschal kann man das nicht sagen, es gibt durchaus sinnvolle Anwendungszenarien. Auch mit vermutlich noch höherem Automatisierungsgrad bei dem der Kunde dann noch nicht mal mehr irgendwas netzwerkmäßig klicken muss. Skalierung von MMO Gameserven etwa. Keine Ahnung ob das auch mit sowas wie Openstack läuft oder schon die nächste Generation mit geheimer Alientechnologie ist, aber bei Star Citizen z.B. braucht es um einen Server zu clonen und eine neue Instanz auf zu machen ca 20 Sekunden. In Spielzeit heißt das quasi wenn alle Server voll sind ist bis der Client alles geladen hat die neue Instanz verfügbar.

  10. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Linuxschaden 30.03.16 - 14:01

    Psy2063 schrieb:
    --------------------------------------------------------------------------------
    > bei Star Citizen z.B. braucht es um einen Server
    > zu clonen und eine neue Instanz auf zu machen ca 20 Sekunden.

    Das beantwortet doch nicht die Frage nach der Skalierung. Die Frage nach der Skalierung ist: was ist n, wenn ich n Prozesse von x ausführen will? Hängt von der Hardware ab. Habe ich bessere Hardware, skaliert es besser (sprich, n ist höcher), kostet aber auch mehr. Habe ich schlechtere Hardware, aber die Software ist intelligent gebaut, skaliert es ebenfalls besser, aber ich spare noch an der Hardware.

    Ob sich eine neue Instanz in 20 Sekunden starten lässt, ist gar nicht die Frage. Die Frage ist, wie viele kann ich parallel laufen lassen, bevor die Hardware anfängt zu schlucken?

    EDIT: Software wird eher selten "gebaucht", Dämlack.



    1 mal bearbeitet, zuletzt am 30.03.16 14:02 durch Linuxschaden.

  11. Re: Da klingelen doch alle Alarmglocken ...

    Autor: derdiedas 30.03.16 - 14:17

    So ein Blödsinn, warum soll in einem großen VM Ware Cluster in dem alle Kommunikation eh innerhalb des Rechnercluster läuft überhaupt noch ein physikalische Kabel gezogen werden?

    Das ist in etwa so als ob Du ein bei Amazon online die Waren aussuchst aber per Postkarte bestellst und eine Barüberweisung bei der Bank machst.

    Das ist und bleibt schlichtweg idiotisch, und Softwaredefined networking wird kommen, genauso wie metal as a Service (maas).

    Eine der größten Unsicherheitsfaktoren was Sicherheit und Stabilität der IT angeht ist die verschissene Verkabelung. Sie kostet unnötig Geld und kann schnell unglaublich komplex werden.

    Gruß ddd

  12. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Psy2063 30.03.16 - 14:37

    alles performed immer besser wenn man mehr und/oder schnellere Hardware und/oder schlankere/optimiertere software benutzt. und genau um diese optimierung geht es hier. Man muss keine X Server vorhalten, von denen die Hälfte einen Großteil des Tages im Leerlauf sind nur damit man dann in der Rushhour doch nicht genug Kapazitäten hat.

    Mal angenommen es gibt 10 Server samt zugehöriger IPs/Netze, davon benutzen die beiden angenommen Kunden je zwei permanent, Kunde A braucht 6 zusätzliche von von 8-12 Uhr und Kunde B von 14-22 Uhr. Dann reichen diese 10 Server, statt 16. Selber Dämlack.

  13. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Linuxschaden 30.03.16 - 14:40

    derdiedas schrieb:
    --------------------------------------------------------------------------------
    > So ein Blödsinn, warum soll in einem großen VM Ware Cluster in dem alle
    > Kommunikation eh innerhalb des Rechnercluster läuft überhaupt noch ein
    > physikalische Kabel gezogen werden?

    Ja, genau. Stattdessen stellt man dann eher eine große Maschine hin, die kostet teuer Geld, aber dann spart man sich das Geld für das Glasfaserkabel ...

    Das ist das Prinzip der Fertigungsanlage, jede Maschine kann nicht alles, aber eine Sache kann sie ziemlich gut. Aber das, mit dem sie gut kann, muss erst mal dorthin gebracht werden. Das kann sich lohnen oder auch nicht. Hosting wird sich allerdings kaum lohnen, weil da kaum Zwischenkommuniziert wird. Da muss ich meine Meinung übrigens revidieren, vor zwei Jahren hätte ich noch z.B. gesagt, dass in einem Bereich, in dem nicht zwischen den Clients kommuniziert wird, ein zentraler Datenbankserver intelligent ist. Heute sage ich, dass, wenn du nicht wirklich erstklassige Festplatten und extraschnellen Arbeitsspeicher zum Cachen hinterbaust, dir die Netzwerklatenz einen Strich durch die Rechnung macht

    > Das ist in etwa so als ob Du ein bei Amazon online die Waren aussuchst aber
    > per Postkarte bestellst und eine Barüberweisung bei der Bank machst.

    Der Vergleich hinkt an so vielen Enden ... auch schon davor der mit Detlef. Bist du zufällig auch irgendwas mit Diplom? Lernt man da heutzutage sowas?

    Ein besserer Vergleich: man gibt eine Bestellung auf, und der, der sie empfängt, gibt das halt weiter. An den, der den Zahlungseingang überwacht, der, der die Rechnung erstellen soll, der, der das Zeuch verpacken soll ... jetzt sagt man, das muss alles zentral werden, und die einzelnen Instanzen müssen voneinander abgeschottet sein. Also kommen alle Mails an einem Konto an. Müssen durchgelesen werden. Dann leitet man das weiter an einen "Manager", der sich lediglich darum kümmert, die Bestellungen an die eigentliche Fillliale weiterzuleiten.

    Und der Typ da muss IMMER noch die Mail lesen und dann sagen, was gemacht werden muss. Man hat jetzt zwei zusätzliche Schichten (Leser der Mails an Zentrale, Manager) ohne Not hinzugefügt.

    Dafür müssen dann die Nutzer halt wissen, an welche Filliale die Bestellung gehen soll. Dafür habe ich auch einen Plan: Vorabsortierung anhand der Lieferaddresse im Mail-Server. Ist wesentlich unkomplizierter. Und im Fehlerfall kann man's ja korrekt weiterleiten.

    > Das ist und bleibt schlichtweg idiotisch, und Softwaredefined networking
    > wird kommen, genauso wie metal as a Service (maas).

    Habe den Apologeten gefunden, der in dem Feld arbeitet. :)

    > Eine der größten Unsicherheitsfaktoren was Sicherheit und Stabilität der IT
    > angeht ist die verschissene Verkabelung. Sie kostet unnötig Geld und kann
    > schnell unglaublich komplex werden.

    Wut?

    Ich habe ja Netzwerktechnik so ein bisschen gemacht. Verkabelung war da noch nicht wirklich ein Problem. Die Probleme kamen eher dadurch, dass zu viel Scheiß auf den Servern lief und die Kisten ständig abstruse Load Peaks erreichten - die waren eigentlich gar keine Load Peaks mehr.

  14. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Linuxschaden 30.03.16 - 14:49

    Psy2063 schrieb:
    --------------------------------------------------------------------------------
    > alles performed immer besser wenn man mehr und/oder schnellere Hardware
    > und/oder schlankere/optimiertere software benutzt. und genau um diese
    > optimierung geht es hier. Man muss keine X Server vorhalten, von denen die
    > Hälfte einen Großteil des Tages im Leerlauf sind nur damit man dann in der
    > Rushhour doch nicht genug Kapazitäten hat.

    Man kann die User auch auf einen Server tun, ohne Virtualisierung zwischenzuschalten (im Sinne eines kompletten Betriebssystems und eines Netzwerks). Notfalls machst du den dann richtig fett, nur damit der dann einen Großteil des Tages im Leerlauf ist, nur damit dann in der Rushhour doch nicht ... merkste selbst, das Argument hingt. Übrig bleibt, den Virtualisierungskram sein zu lassen.

    > Selber Dämlack.

    OK, jetzt hast du dich selbst zum Dämlack gemacht. Denn ich habe mich selbst als "Dämlack" bezeichnet, als ich meinen Rechtschreibfehler korrigierte ... m(

    Und sowas lernt man also heutzutage auf einer Uni. Soso. Verstehe. Namen sind halt Schall und Rauch.

  15. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Moe479 30.03.16 - 15:09

    virtuelle maschienen nahtlos je nach anforderung flexibel auf die garde dafür entsprechend ihrer last auf die best geeignetste hardware befördern zu können ist an sich schon interessant ... gerade, wenn die last nicht ständig ähnlich hoch ist, sondern starken schwankungen unterliegt ...

    stell dir vor ein application server schiebt gegen 9:00 Uhr und 14:00 vollast, vor 9:00 sind kaum anfragen, gegen 12:00 gerade zu ein null-aufkommen und nach 14:00 ebbt es langsam ab bis nach 18:00 bis 9:00 wiederum kaum zu bearbeitende anfragen laufen ... und am wochenende und feiertagen passiert auch nichts ...

    nun kann man die freiwerdene leistung anderen vms auf dieser maschiene bereitstellen, variabel virtuelle cpus und ram zuweisen ... aber wenn alle gerade nicht genug ackern wird potenzielle leistung verschwendet und hier käme ein 'nahtloser' umzug dieser VMs auf eine andere hardware und ebenbsolcher hinzug von VMs von anderer hardware einem segen gleich, denn während andere hardware gerade nicht hinterher kommt gammelt diese ja gerade rum!

    sdn macht es schon ein stück weit nahtloser nach außen hin VMs dynamisch ihres bedarfes nach über hardware-parks hinweg platzieren zu können.

    natürlich gibt es schwellwerte, vorallem den der 'kosten für einen umzug'.

    ein solches system müsste auch automatisch lernen welche vm wann viel leistung im schnitt benötigt um diese möglichst intelligent zu mit anderen zu platzieren um möglichst jede hardware im park möglichst gleich auszulasten bzw. möglchst nahe am maximum zu befeuern, damit mehr rechenzeit und speicher für weitere vms bereit steht.



    4 mal bearbeitet, zuletzt am 30.03.16 15:23 durch Moe479.

  16. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Psy2063 30.03.16 - 15:12

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Man kann die User auch auf einen Server tun, ohne Virtualisierung
    > zwischenzuschalten (im Sinne eines kompletten Betriebssystems und eines
    > Netzwerks). Notfalls machst du den dann richtig fett, nur damit der dann
    > einen Großteil des Tages im Leerlauf ist, nur damit dann in der Rushhour
    > doch nicht ... merkste selbst, das Argument hingt. Übrig bleibt, den
    > Virtualisierungskram sein zu lassen.

    eben nicht, in dem Beispielszenario werden 40% Hardware eingespart. Es gibt keinen Grund alles richtig Fett zu machen, wenn sich mehrere Kunden über den Tag verteilt Ressourcen teilen können.

    > OK, jetzt hast du dich selbst zum Dämlack gemacht. Denn ich habe mich
    > selbst als "Dämlack" bezeichnet, als ich meinen Rechtschreibfehler
    > korrigierte ... m(

    ok das war für mich in dem Kauderwelsch so irgendwie nicht zu erkennen, sorry

    > Und sowas lernt man also heutzutage auf einer Uni. Soso. Verstehe. Namen
    > sind halt Schall und Rauch.

    Uni? Namen? Kennen wir uns?

  17. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Grinskeks 30.03.16 - 15:16

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------

    > Virtualisierung in Verbindung mit Netzwerken halte ich für eine blöde Idee.
    > Hardware ist billig, schnell, und funktioniert, Auf der anderen Seite
    > wundert mich es nicht; IT-ler in jeder Richtung gehen dazu über, die heute
    > zur Verfügung stehende Rechenleistung für Blödsinn zu verwenden, anstatt
    > ordentlich zu skalieren.

    Wer sich mit der Materie beschäftigt und offen für die Anwendungsfälle ist, erkennt auch schnell deren Vorzüge.

    Portbasierte Vlans sorgen für optimierten Traffic im Netzwerk, organisieren Projektteams und verhindern grundsätzlich Zugriff auf Ressourcen, die nicht zugeordnet werden sollen.
    Ich will denjenigen sehen, der sich in solchen Fällen mit Patchkabeln und Switches bewaffnet und anfängt umzukabeln. Das hört sich nach dem klassischen Turnschuh-Administrator an, der begrenzt Ahnung aber viel Meinung hat.

    Die Hardware muss immer schneller werden, weil die Ansprüche wachsen und einfach die Zeit fehlt, es "richtig" zu machen. Richtig ist in diesem Kontext mit "teuer", "ineffizient", "langsam" und "veraltet" gleichzusetzen.
    Wer das nicht verstanden hat, sieht an der Realität vorbei.

    Meine Empfehlung: Objektiv betrachten und dann nach dem jeweiligen Anwendungszweck beurteilen.

    Gruss
    Grinskeks

  18. Re: Da klingelen doch alle Alarmglocken ...

    Autor: derdiedas 30.03.16 - 15:16

    Es geht nicht darum eine neue Maschine aufzubauen, sondern wenn man eh schon alles virtualisiert das auch konsequent durchzuführen und nicht bei den letzten 10% stehenzubleiben.

    Warum soll ein IP Paket noch außerhalb eines Rechnerclusters laufen wenn das nicht nötig ist?

  19. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Sinnfrei 30.03.16 - 15:31

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Virtualisierung in Verbindung mit Netzwerken halte ich für eine blöde Idee.
    > [...]
    > Da googelt man dem Autor hinterher und
    > [...]
    > Mit Virtualisierung, ja klar ... hahaha.

    Wird Dich übrigens interessieren, dass Google praktisch nur noch auf SDN setzt ... ganz so blöd kann es da wohl doch nicht sein, was?

    __________________
    ...

  20. Re: Da klingelen doch alle Alarmglocken ...

    Autor: Linuxschaden 30.03.16 - 16:14

    Psy2063 schrieb:
    --------------------------------------------------------------------------------
    > Linuxschaden schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Man kann die User auch auf einen Server tun, ohne Virtualisierung
    > > zwischenzuschalten (im Sinne eines kompletten Betriebssystems und eines
    > > Netzwerks). Notfalls machst du den dann richtig fett, nur damit der dann
    > > einen Großteil des Tages im Leerlauf ist, nur damit dann in der Rushhour
    > > doch nicht ... merkste selbst, das Argument hingt. Übrig bleibt, den
    > > Virtualisierungskram sein zu lassen.
    >
    > eben nicht, in dem Beispielszenario werden 40% Hardware eingespart. Es gibt
    > keinen Grund alles richtig Fett zu machen, wenn sich mehrere Kunden über
    > den Tag verteilt Ressourcen teilen können.

    ... darum geht es gar nicht mehr. Wie man die jetzt verteilt oder nicht verteilt, das ist in meinem Kritikpunkt doch komplett unerheblich. Das Beispiel habe ich angebracht, um damit anzusagen, dass diese Art der Virtualisierung (alles auf eine Maschine packen und dann Betriebssysteme darum ziehen) dumm ist. Maschinen für mehrere Clients zu stellen kann man schließlich auch so. Siehe ulimits und Benutzerkontensteuerung. Notfalls emuliert man mit chroot ein Basissystem, wenn der Nutzer das unbedingt braucht.

    Oder anders: mir geht es gerade nicht um Lastenverteilung, sondern Lastenvermeidung.

    > Uni? Namen? Kennen wir uns?
    Ugh, da habe ich dich mit warten_auf_godot verwechselt. Mein Fehler, ich bitte um Verzeihung.

    Moe479 schrieb viel.

    Und jetzt nur das Eine: brauche ich virtuelle Maschinen, um jemanden umzuziehen? Ich weiß ja nicht, wie du das siehst, aber in meinem Schema habe ich erst mal für jeden Kunden einen Ordner in /home, und wenn ich den umziehen will, dann kopiere ich diesen Ordner und lasse den DNS-Server auf eine andere Maschine zeigen. Dafür brauche ich keine virtuelle Maschine. Oder?

    @Grinskeks:

    Noch mal: VLANs != virtuelle Switche. Über VLANs sage ich gar nichts, da erkenne ich sogar einen Nutzen drin. Habe ich sogar weiter oben geschrieben, dass Port-basierte VLANs für Skalierbarkeit und Übersicht bekannt sind.

    > Die Hardware muss immer schneller werden, weil die Ansprüche wachsen und einfach
    > die Zeit fehlt, es "richtig" zu machen. Richtig ist in diesem Kontext mit "teuer",
    > "ineffizient", "langsam" und "veraltet" gleichzusetzen. Wer das nicht verstanden hat,
    > sieht an der Realität vorbei.

    Die Ansprüche sind noch die gleichen wie vor zwanzig Jahren, nur werden diese jetzt auch von sehr viel mehr Leuten geteilt. Aber mit dem alten, gut skalierbaren Systemen kamen die jungen IT-ler nicht klar, deswegen wurde das dann alles wegabstrahiert.

    Nicht falsch verstehen: Abstrahierung ist nicht böse. Aber unnötige Abstrahierung ist böse. Und unnötige Abstrahierung wird heute praktisch überall betrieben, nicht aus Zeitmangel - OK, vielleicht das auch, aber indirekt.

    Da gab es doch diesen einen Artikel von einem Typen, der am Windows-Kernel mitgearbeitet hat, und sich darüber beschwert, dass das alte, relativ gut laufende System (keine Ahnung, ob das stimmt, kenne Windows nur als Kunde, und bin davon unterwältigt) von neuen Leuten kaputt gemacht wird, weil diese nicht kapieren, wie es funktioniert. Ich sehe das überall so. Und dabei werde ich auch zu diesen "jungen Leuten" gezählt, obwohl ich überhaupt gar nicht so bin. Nein, die sind einfach inkompetent.

    Nicht schlimm, war jeder Mal. Aber heute gibt es keinen Leidensdruck mehr, es ordentlich zu machen. Und dann wächst man nicht über sich hinaus.

    Sinnfrei schrieb:
    --------------------------------------------------------------------------------
    > Wird Dich übrigens interessieren, dass Google praktisch nur noch auf SDN
    > setzt ... ganz so blöd kann es da wohl doch nicht sein, was?

    Hihi, das ist dein Argument? Ich bitte dich. Erinnert sich noch einer an die Zeiten, als Torvalds in einem Raum voller Google-Ingenieure gesagt hat, dass er die meisten von ihnen für komplett inkompetent hält? Was erwartet mal auch von Leuten, die Python verwenden?

    Aber davon will ich gar nicht erst anfangen.

    EDIT: Doch, eigentlich will ich das. Erinnert sich noch jemand daran, wie der SSL-Code in Python ein Debug-Flag gesetzt hat, was bei SSL_read und SSL_write immer ein sleep(1) gemacht hat? Ist allerdings auch schon wieder 6 Jahre her, und irgendeiner WIRD das jetzt verargumentieren wollen ... :)



    1 mal bearbeitet, zuletzt am 30.03.16 16:27 durch Linuxschaden.

  1. Thema
  1. 1
  2. 2
  3. 3

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. dSPACE GmbH, Paderborn
  2. über Hays AG, Dortmund
  3. Haufe Group, Hannover, Freiburg
  4. Amprion GmbH, Pulheim

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. be quiet! Straight Power 11 Platinum 850Watt PC-Netzteil für 154,90€, Heitronic...
  2. 172,90€
  3. (u. a. Razer Basilisk Ultimate Wireless Gaming-Maus und Mouse Dock für 129€, Asus ROG Strix G17...
  4. (u. a. Samsung GQ65Q80T 65 Zoll QLED für 1.199€, Corsair HS60 Over-ear-Gaming-Headset Carbon...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme