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

Da klingelen doch alle Alarmglocken ...

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema


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

    Autor: Sinnfrei 30.03.16 - 16:25

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    >
    > 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.

    Du hast die Ironie nicht verstanden. Du nutzt ein Produkt was auf SDN basiert - wie Milliarden andere Menschen - vermutlich täglich, aber beschwerst Dich, dass die zugrunde liegende Technik eine blöde Idee ist ...

    __________________
    ...

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

    Autor: Linuxschaden 30.03.16 - 16:34

    Sinnfrei schrieb:
    --------------------------------------------------------------------------------
    > Du hast die Ironie nicht verstanden. Du nutzt ein Produkt was auf SDN
    > basiert - wie Milliarden andere Menschen - vermutlich täglich, aber
    > beschwerst Dich, dass die zugrunde liegende Technik eine blöde Idee ist ...

    Ach, tue ich das? Soso, interessant ...

    Tja, duckduckgo und Startpage, tut mir Leid, aber ihr seid jetzt wohl google. Das Internet sagt so.

    Sarkasmus beiseite: Noch mal, ich finde es lustig, weil ich den Gedankengang dahinter nicht begreife. Persönlich ist mir das doch egal, was die ausrollen, aber wenn sie Scheiße ausrollen, dürfen die sich nicht wundern, dass ich mich über sie lustig mache.

    Das ist wie mit diesen ganzen Wordpress-Seiten. Ich brauche ein bisschen mehr HTML-Kenntnisse, wie ich beim Schreiben dieser Postings verwende, als wenn ich ein Tagebuch/Plichtenheft in HTML schreiben will. Ist wirklich nicht viel mehr. Ich hab's ausprobiert. Aber die Leute installieren sich lieber Wordpress, welches schon seit Ewigkeiten verseucht ist mit Lücken. Da mache ich mich auch lustig drüber und habe so dermaßen kein Mitleid mit den Leuten. What now?

    EDIT: "wie" statt "die ich beim"



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

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

    Autor: madkiss 30.03.16 - 16:50

    "Scheiße ausrollen" ist eine feine Metapher. Die muss ich mir merken. :)

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

    Autor: Sinnfrei 30.03.16 - 17:25

    Vielleicht solltest Du dann nicht von "googeln" schreiben, wenn Du nicht "googeln" meinst?

    Edit: Und Du bist auch nie auf Youtube? Google.com und youtube.com haben Alexa Global Page Rank 1 und 3 - so schlecht können die wohl nicht sein, aber Hauptsache Du weißt alles besser. Ich möchte mal Deine Lösung für ein weltweites Netzwerk mit Milliarden Zugriffen täglich sehen ... obwohl, eher lieber doch nicht.

    __________________
    ...



    1 mal bearbeitet, zuletzt am 30.03.16 17:34 durch Sinnfrei.

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

    Autor: gaym0r 30.03.16 - 17:29

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > 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.

    Dann würde ich mal gerne wissen wie du es machen würdest.

    Nimm ein größeres mittelständisches Unternehmen. 4000 Mitarbeiter, 2000 in der Zentrale, der Rest weltweit verteilt, manchmal an Standorten mit <50 Mitarbeitern. Selbst an den kleinen Standorten werden mehr als ein Server benötigt. (DC, File-Server, SCCM, Windchill etc.pp.)
    Wie willst du das machen? 5 physikalische Maschinen? Alle Dienste auf einem dicken Host laufen lassen? Was spricht gegen 1-2 physikalische Hosts für mehrere VMs?
    Und wie sähe deine Infrastruktur in der zentrale aus? Wie willst du hohe Ausfallsicherheit bei gleichzeitig geringen Kosten garantieren? Es ist mir ein Rätsel.

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

    Autor: gaym0r 30.03.16 - 17:30

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

    Eh? Irgendwie muss es ja zum Anwender kommen.

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

    Autor: gaym0r 30.03.16 - 17:34

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > 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?

    Und das ist dein Argument? Weil Torvalds (wahrscheinlich vergötterst du ihn?) gesagt hat, die Ingenieure taugen nichts, ist das auch so? Ich sag jetzt einfach mal, dass du auch inkompentent bist und die Diskussion ist vorbei. Denkst du es ist so einfach?

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

    Autor: cry88 30.03.16 - 17:48

    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. 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 ...

    Der Vorteil von SDN ist nur begrenzt die Performance. Es geht hier um das Management. Es wird primär für große Netzwerke verwendet, die von hunderten kleinen Admins für unterschiedliche Zwecke verwendet werden. Die kannst du weder alle in dein Netzwerk lassen um dort Kabel zu ziehen, noch kannst du deine Techniker losschicken um die Kundenwünsche umzusetzen. Das funktioniert einfach nicht.

    Primär nutzen deswegen auch nur große Internet Konzerne oder Cloud Anbieter SDN.

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

    Autor: Linuxschaden 30.03.16 - 17:58

    gaym0r schrieb:
    --------------------------------------------------------------------------------
    > Dann würde ich mal gerne wissen wie du es machen würdest.
    >
    > Nimm ein größeres mittelständisches Unternehmen. 4000 Mitarbeiter, 2000 in
    > der Zentrale, der Rest weltweit verteilt, manchmal an Standorten mit <50
    > Mitarbeitern. Selbst an den kleinen Standorten werden mehr als ein Server
    > benötigt. (DC, File-Server, SCCM, Windchill etc.pp.)

    DC/SCCM übersetze ich mal mit SSH/VNC, bei Windchill habe ich seit Jahr und Tag dessen Sinn nicht verstanden.

    Für lokale Dienste und für Sachen, bei denen man Cachen kann (File-Server), würde ich ein oder zwei lokale kleine Server dranhängen, den zweiten Hauptsächlich zur Sicherung. Ist nicht hochzuverlässig, weiß ich selbst, ich will das Beispiel aber klein halten. Da muss dann halt ein Admin stationiert sein bei den Standorten.

    Bei den zentralen Diensten kommt es darauf an, ob diese oft Daten von außerhalb abfragen. Da sind zu viele Variablen offen. Pauschal würde ich aber erst mal sagen, dass ich zwei fette Server hinstellen würde, bei denen jeder Dienst hinter einem eigenen Benutzer läuft. Der zweite Server ist auch hier wieder dafür, falls der erste Server fratze geht. Außerdem noch eine Datensicherung reinschalten - sogar zwei, wenn es extra sicher sein soll. Dafür brauche ich dann, sagen wir, zwei NAS, oder Tapesicherungen.

    Auf die freigegebenen Daten der Zentrale können die Niederlassungen über SSHFS zugreifen, das ist verschlüsselt, und wenn jede Maschine in der Niederlassung den vorgeschalteten Server fragt, kann der Cachen wie ein Proxy.

    Dazu muss ich aber auch eines sagen: Ich habe nicht Admin gelernt. Also, zumindest nicht offiziell. Ich kenne die Konzepte, ich kenne grob, was man tun und lassen sollte. Aber alles weiß ich nicht. Was ich weiß, ist ...

    > Wie willst du das machen? 5 physikalische Maschinen? Alle Dienste auf einem
    > dicken Host laufen lassen? Was spricht gegen 1-2 physikalische Hosts für
    > mehrere VMs?

    VMs für Datensicherheit? Katastrophe. Wenn die Hardware aushaucht, muss schnell Ersatz her.
    Und dagegen spricht, wenn alle darauf Zugreifen wollen, dass VMs, wie ich schon seit Seite 1 beschreibe, und da hat mir noch keiner ein Gegenargument zu geliefert, und das möchte ich mal langsam haben, weil ich nicht verstehe, wie man das ignorieren kann - VMs skalieren nicht.

    > Und wie sähe deine Infrastruktur in der zentrale aus? Wie willst du hohe
    > Ausfallsicherheit bei gleichzeitig geringen Kosten garantieren? Es ist mir
    > ein Rätsel.

    Steht oben.

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

    Autor: Isotopp 30.03.16 - 18:02

    Linuxschaden schrieb:
    > Cloud braucht keine Sau, Virtualisierung braucht keine Sau.

    Du hast gut 10 Jahre Hardware-Entwicklung verpaßt.

    Ich habe es Dir einmal aufgemalt
    http://www.slideshare.net/isotopp/was-ist-cloud

    und vorgelesen
    https://www.youtube.com/watch?v=Yk0VTd2eUgM


    Disclaimer: Ich bin Kollege des Artikelautors.
    Disclaimer: Ich habe schon mal Rechenzentren gebaut.



    1 mal bearbeitet, zuletzt am 30.03.16 18:03 durch Isotopp.

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

    Autor: Linuxschaden 30.03.16 - 18:11

    Isotopp schrieb:
    --------------------------------------------------------------------------------
    > Linuxschaden schrieb:
    > > Cloud braucht keine Sau, Virtualisierung braucht keine Sau.
    >
    > Du hast gut 10 Jahre Hardware-Entwicklung verpaßt.

    Nein, die meisten können durch Hardware Schludrigkeit kompensieren.

    > Ich habe es Dir einmal aufgemalt

    Diskrepanz zwischen Seite 3/4 und 5. Wie kommt man zwischen "Mein Server hat zu viel Bumms!" zu "Wir virtualisieren!"? Warum?! Es ist und bleibt Hirnriss. Es ergibt keinen Sinn. Die Dienste kann ich auch ohne VM auf eine Maschine packen. Habt ihr noch nie einen HTTP-Server von innen gesehen, noch nie SSH konfiguriert? Nicht nur schafft ihr mehr Bloat auf der Maschine ohne Not, sondern auch Angriffsfläche.

    http://heise.de/-2074943

    Ohne Not! Das alles kann ich auch ohne VM haben. Immer noch auf der gleichen Maschine. Wozu?!



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

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

    Autor: Isotopp 30.03.16 - 18:14

    Linuxschaden schrieb:
    > Virtualisierung und Skalierbarkeit funktioniert nicht. Zumindest nicht,
    > wenn wir dabei sind, ganze Netzwerke virtuell zu bauen.

    Aber sicher geht das. Du hast DSL daheim. Das hast Du, weil MPLS Netzwerkvirtualisierung deutschlandweit skalieren kann.

    Das skaliert besser als VLAN, weil VLAN eine konvergierende Konfiguration netzwerkweit braucht (ein neuer VLAN-Tag muß auf allen beteiligten Switches identisch überall konfiguriert sein), während MPLS eine next-hop Sache ist, die zwischen den Ports beteiligter Switches geregelt wird.

    Beides wird von modernen Switches in Hardware erledigt. Tatsächlich sind moderne Switches auch nur Linux-Rechner mit sehr vielen Netzwerkkarten mit sehr viel Hardware-Support.

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

    Switch-Konfiguration und Paket-Forwarding-Regeln sollte man nicht verwechseln. Einen Switch konfiguriert man einmal und dann ist gut. Paket-Forwarding-Einträge regeln Switches anders und dynamisch (das im Artikel erwähnte Contrail zum Beispiel via BGP).

    > Ich komme aus der Linux-Ecke. Dort haben wir ulimits, um die Resourcen von
    > Nutzern zu beschränken,

    Du, die Linux-Ecke hat seit mehr als 5 Jahren bessere Mechanismen als ulimits um Ressourcen zu beschränken. Du willst cgroups nachlesen.

    Dazu orthogonal sind Mechanismen, um Sichtbarkeit von Ressourcen zu regeln, also das Äquivalent von chroot. In modernem Linux sind das die sechs Namespaces, darunter auch die im Artikel erwähnten Network-Namespaces, mit denen man pro Namespace lokale Interfaces, Routingtabellen und iptables-Regeln haben kann.

    Und ja, das ist nützlich, weil es einem Prozeß oder einer Gruppe von Prozessen erlaubt, einen eigenen Regelsatz für die Paketverarbeitung zu haben.

    > 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?

    Weil Du dann eine physikalische Maschine in getrennte administrative Domains aufteilen kannst und Systemverwaltung für Teile Deiner Hardware an Dritte delegieren kannst ohne die Kontrolle über die physikalische Hardware abzugeben.

    Das ist ein Geschäftsmodell. Das heißt, wenn Du es korrekt umsetzt, macht es Deinen Kühlschrank voll.

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

    Autor: Linuxschaden 30.03.16 - 18:36

    gaym0r schrieb:
    --------------------------------------------------------------------------------
    > Und das ist dein Argument? Weil Torvalds (wahrscheinlich vergötterst du
    > ihn?) gesagt hat, die Ingenieure taugen nichts, ist das auch so? Ich sag
    > jetzt einfach mal, dass du auch inkompentent bist und die Diskussion ist
    > vorbei. Denkst du es ist so einfach?

    Ah, nein, soweit als ihn zu vergöttern würde ich nicht gehen.

    Aber diese Diskussion ("Google verwendet es ja auch") ist ja bereits ohne wirkliche Faktenbasis gestartet worden. Weil Google es verwendet, muss es ja gut sein. Dass die da auch unfähige Leute haben, wird hier komplett ignoriert. Dass die dann so viel Hardware verwenden müssen, weil's sonst nicht ausreicht - wird auch ignoriert.

    Aber weißt du was? Für mich ist es einfacher, wenn du einfach sagst, dass ich ebenfalls inkompetent bin, und dann habe ich meine Ruhe.

    Isotopp schrieb:
    --------------------------------------------------------------------------------
    > Das skaliert besser als VLAN, weil VLAN eine konvergierende Konfiguration
    > netzwerkweit braucht (ein neuer VLAN-Tag muß auf allen beteiligten Switches
    > identisch überall konfiguriert sein), während MPLS eine next-hop Sache ist,
    > die zwischen den Ports beteiligter Switches geregelt wird.

    ... in meinem Weltbild kann ich meinem VLAN-fähigem Switch sagen, dass er bestimmte Ports für bestimmte VLANs reserviert. Dann brauche ich kein Tag. Das habe ich auch schon in meinem ... zweiten oder dritten Post geschrieben? Keine Ahnung, aber ein VLAN-Tag würde ich nicht dafür einsetzen, weil - ich bin eine kaputte Aufnahme - port-basierte VLANs für Skalierbarkeit und Übersichtlichkeit bekannt sind.

    Da würde ich mal gerne wissen, was schneller ist.

    > Beides wird von modernen Switches in Hardware erledigt. Tatsächlich sind
    > moderne Switches auch nur Linux-Rechner mit sehr vielen Netzwerkkarten mit
    > sehr viel Hardware-Support.

    Ähm, ja, genau. Darum geht es. Anstatt, dass ich das also virtuell machen lasse über eine VM, lasse ich es lieber Hardware machen, die dafür konzipiert wurde. Die Hardware-Support hat. Die schnell ist. Die skaliert.

    > Switch-Konfiguration und Paket-Forwarding-Regeln sollte man nicht
    > verwechseln. Einen Switch konfiguriert man einmal und dann ist gut.
    > Paket-Forwarding-Einträge regeln Switches anders und dynamisch (das im
    > Artikel erwähnte Contrail zum Beispiel via BGP).

    Wo rede ich denn hier bitte von Paket-Forwarding? Ich habe noch gelernt, dass Switche Management-Konsolen haben, auf die man zugreifen kann, und über die man auch die Zuordnung der Ports ändern kann bei Belieben. Statisch soll daran halt sein, dass der Admin die Zugehörigkeit des Ports festlegt und diese nicht vom VLAN-Tag bestimmt wird, was das Protokol bricht und außerdem zusätzlichen Aufwand in Hardware bedeutet.

    > Du, die Linux-Ecke hat seit mehr als 5 Jahren bessere Mechanismen als
    > ulimits um Ressourcen zu beschränken. Du willst cgroups nachlesen.

    Oder cgroups. Sind halt relativ neu. Ist immer noch kein Grund, Virtualisierung auszurollen.

    Es geht darum, Prozesse zu limitieren. Oder Prozessgruppen. Mit virtuellen Maschinen kann ich das auch. Aber warum sollte ich? Dann kann ich ulimit, oder besser, cgroups verwenden.

    > Weil Du dann eine physikalische Maschine in getrennte administrative
    > Domains aufteilen kannst und Systemverwaltung für Teile Deiner Hardware an
    > Dritte delegieren kannst ohne die Kontrolle über die physikalische Hardware
    > abzugeben.

    ... und warum kann ich das nicht ohne virtuelle Maschine? Meines Wissens kann ich das nämlich (über erwähntes chroot, in der dann ein kleinerer Admin immer noch Admin über, sagen wir, seinen Standort ist - und die Nutzer sind dann immer noch nur Nutzer. Und wenn der Admin Blödsinn macht, dann betrifft das nur sein /, nicht das / der Maschine).



    1 mal bearbeitet, zuletzt am 30.03.16 18:37 durch Linuxschaden.

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

    Autor: gaym0r 30.03.16 - 18:41

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > gaym0r schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Dann würde ich mal gerne wissen wie du es machen würdest.
    > >
    > > Nimm ein größeres mittelständisches Unternehmen. 4000 Mitarbeiter, 2000
    > in
    > > der Zentrale, der Rest weltweit verteilt, manchmal an Standorten mit <50
    > > Mitarbeitern. Selbst an den kleinen Standorten werden mehr als ein
    > Server
    > > benötigt. (DC, File-Server, SCCM, Windchill etc.pp.)
    >
    > DC/SCCM übersetze ich mal mit SSH/VNC

    Wat?

    > bei Windchill habe ich seit Jahr und
    > Tag dessen Sinn nicht verstanden.

    Warum nicht?

    > Für lokale Dienste und für Sachen, bei denen man Cachen kann (File-Server),
    > würde ich ein oder zwei lokale kleine Server dranhängen, den zweiten
    > Hauptsächlich zur Sicherung.

    Als Sicherung haben wir EMC DataDomains und die sind super.
    Du würdest also jedes System zwei mal kaufen?

    > st nicht hochzuverlässig, weiß ich selbst,
    > ich will das Beispiel aber klein halten. Da muss dann halt ein Admin
    > stationiert sein bei den Standorten.

    Warum lokaler Admin?
    In dem genannten Beispiel ist die weltweite IT 50 Mann stark, bei 30 Standorten. Und du willst an jedem Standort einen Admin haben? Realitätsfern. Vorallem weil es auch ohne wunderbar funktioniert.

    > Bei den zentralen Diensten kommt es darauf an, ob diese oft Daten von
    > außerhalb abfragen. Da sind zu viele Variablen offen. Pauschal würde ich
    > aber erst mal sagen, dass ich zwei fette Server hinstellen würde, bei denen
    > jeder Dienst hinter einem eigenen Benutzer läuft. Der zweite Server ist
    > auch hier wieder dafür, falls der erste Server fratze geht.


    Hm. Wir haben aktuell 7 dicke VMware Hosts, die allesamt am Pöller sind. Dazu kommen noch ca. 35 physikalische Server (und zwei dicke Rechencluster).

    Das sind ganz normale Zahlen für ein solches Unternehmen. Und das willst du über zwei dicke Server abwickeln? Ist ja süß.

    > Außerdem noch
    > eine Datensicherung reinschalten - sogar zwei, wenn es extra sicher sein
    > soll. Dafür brauche ich dann, sagen wir, zwei NAS, oder Tapesicherungen.

    Yop, so haben wir es.

    > Auf die freigegebenen Daten der Zentrale können die Niederlassungen über
    > SSHFS zugreifen, das ist verschlüsselt, und wenn jede Maschine in der
    > Niederlassung den vorgeschalteten Server fragt, kann der Cachen wie ein
    > Proxy.

    Du musst bedenken, dass ziemlich viel zentral abgefragt wird und speziell nach Indien und Afrika nur dünne Leitungen (<4 Mbit/s) liegen. Caches haben wir natürlich, aber reicht dennoch nicht.

    > Dazu muss ich aber auch eines sagen: Ich habe nicht Admin gelernt. Also,
    > zumindest nicht offiziell. Ich kenne die Konzepte, ich kenne grob, was man
    > tun und lassen sollte. Aber alles weiß ich nicht. Was ich weiß, ist ...

    Dafür lässt du hier aber ziemlich viel ab.

    > > Wie willst du das machen? 5 physikalische Maschinen? Alle Dienste auf
    > einem
    > > dicken Host laufen lassen? Was spricht gegen 1-2 physikalische Hosts für
    > > mehrere VMs?
    >
    > VMs für Datensicherheit? Katastrophe. Wenn die Hardware aushaucht, muss
    > schnell Ersatz her.

    Wer sprach von Datensicherheit? 2 physikalische Hosts für die VMs und du hast eine Ausfallsicherheit, falls ein Host hops geht. Bei physikalischen Servern ist der Server erstmal tot.
    Backup wird natürlich trotzdem gemacht.

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

    Autor: Linuxschaden 30.03.16 - 19:14

    gaym0r schrieb:
    --------------------------------------------------------------------------------
    > Wat?

    Domain Controller und verteilter Systemmanager. Kann ich in Linux komplett über SSH abwickeln. Für die, die's grafisch haben wollen, auch VNC.

    Wenn's dir nur darum geht, WARUM ich das mache - nun, weil ich halt kaum mit Windows arbeite und dann mit Linux-Äquivalenten arbeite.

    > Warum nicht?

    Ich verstehe den Anreiz nicht, größere Projekte über spezielle Softwarelösungen verwalten zu wollen. Sagen wir mal, wir haben ein Projekt für Produkt X, was an verschiedenen Standorten xxx wird (xxx kann hier für mehrere Sachen stehen - gebaut, vertrieben, verkauft ...). Sagen wir, bisher stand der Plan für X fest, aber jetzt hat sich was geändert, und alle Stellen müssen davon benachrichtigt werden. Das tut Windchill (soweit ich das verstanden habe) - aber warum kann ich nicht einfach eine Rundmail versenden? Oder jeweils an eine Mail-Gruppe? Damit die Programmierer Bescheid wissen, dass X jetzt ABC können muss. Dann kann der Teamleiter dem Vertrieb sagen, dass durch ABC die Entwicklungszeit um drei Monate verlängert wird. Dann kann der Vertrieb mit der Werbung warten.

    Warum brauchen wir für die Kommunikation dieser Daten ein eigenes Programm?

    > Als Sicherung haben wir EMC DataDomains und die sind super.
    > Du würdest also jedes System zwei mal kaufen?

    Für die lokalen Netzwerke, ja. Entweder das, oder ich erstelle die Konten direkt auf den fetten Servern in der Zentrale. Der dann immer noch keine Virtualisierung braucht. Das bedeutet dann zwar höhrere Latenzen, aber die Backups wären dadurch leichter durchzuführen.

    > Warum lokaler Admin?
    > In dem genannten Beispiel ist die weltweite IT 50 Mann stark, bei 30
    > Standorten. Und du willst an jedem Standort einen Admin haben?
    > Realitätsfern. Vorallem weil es auch ohne wunderbar funktioniert.

    Wenn das Netzwerk in einem Standort ausfällt? Wenn generell dort mal was ausfällt? Keinen Admin haben? Du bist mutig.

    > Hm. Wir haben aktuell 7 dicke VMware Hosts, die allesamt am Pöller sind.
    > Dazu kommen noch ca. 35 physikalische Server (und zwei dicke
    > Rechencluster).
    >
    > Das sind ganz normale Zahlen für ein solches Unternehmen. Und das willst du
    > über zwei dicke Server abwickeln? Ist ja süß.

    Ich weiß ja nicht, was die genau machen. Bisher war immer die Rede von "Hilfe, wir haben zu viel Rechenkapazität".

    Natürlich kann ich noch mehr Maschinen hinterklemmen.

    > Du musst bedenken, dass ziemlich viel zentral abgefragt wird und speziell
    > nach Indien und Afrika nur dünne Leitungen (<4 Mbit/s) liegen. Caches haben
    > wir natürlich, aber reicht dennoch nicht.

    Ja, deswegen habe ich an die lokalen Server gedacht. Und wo ein Server ist, sollte auch ein Admin sein. Eigentlich sollte schon da, wo nur ein paar Computer rumstehen, schon ein Admin sein. Und wenn es nur um "starten Sie die Maschine neu" geht.

    > Wer sprach von Datensicherheit? 2 physikalische Hosts für die VMs und du
    > hast eine Ausfallsicherheit, falls ein Host hops geht. Bei physikalischen
    > Servern ist der Server erstmal tot.
    > Backup wird natürlich trotzdem gemacht.

    Ach so meinst du das. Ich dachte gerade daran, dass du die Backups auf der gleichen physikalischen Maschine, nur andere VM machen willst.

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

    Autor: derdiedas 30.03.16 - 20:29

    Wie kommst Du darauf das alles zum Anwender muss?

    Nicht alles was in einer virtuellen Umgebung läuft ist für außerhalb gedacht, sonder inter Server Kommunikation (Cluster für den AppServer, Cluster für die Datenbank, Cluster für das SAN usw... usw... usw...)

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

    Autor: gaym0r 31.03.16 - 11:32

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > gaym0r schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wat?
    >
    > Domain Controller und verteilter Systemmanager. Kann ich in Linux komplett
    > über SSH abwickeln. Für die, die's grafisch haben wollen, auch VNC.

    SCCM ist hier für die Verteilung von dutzenden Applikationen inkl. Installation von 4 Betriebssystemen zuständig.
    Und du willst dann Ingenieure mit aufwendingen CAD-Programmen auf einem kleinen Terminalserver arbeiten lassen?

    > Wenn's dir nur darum geht, WARUM ich das mache - nun, weil ich halt kaum
    > mit Windows arbeite und dann mit Linux-Äquivalenten arbeite.
    >
    > > Warum nicht?
    >
    > Ich verstehe den Anreiz nicht, größere Projekte über spezielle
    > Softwarelösungen verwalten zu wollen. Sagen wir mal, wir haben ein Projekt
    > für Produkt X, was an verschiedenen Standorten xxx wird (xxx kann hier für
    > mehrere Sachen stehen - gebaut, vertrieben, verkauft ...). Sagen wir,
    > bisher stand der Plan für X fest, aber jetzt hat sich was geändert, und
    > alle Stellen müssen davon benachrichtigt werden. Das tut Windchill (soweit
    > ich das verstanden habe) - aber warum kann ich nicht einfach eine Rundmail
    > versenden?

    Weil wir nicht mehr im letzten Jahrhundert leben? Warum verschicken wir Mails, wenns doch auch per Post geht?
    Alles was man zu Windchill wissen muss steht hier: http://de.ptc.com/product-lifecycle-management/windchill
    Desweiteren ist der Windchill Cache Server eine feine Sache.

    Wenn du immer noch sagst Windchill braucht man nicht... Naja...

    > > Als Sicherung haben wir EMC DataDomains und die sind super.
    > > Du würdest also jedes System zwei mal kaufen?
    >
    > Für die lokalen Netzwerke, ja.

    Die Backups werden auch an die zentrale geleitet. Komprimiert und dedubliziert.

    > Entweder das, oder ich erstelle die Konten
    > direkt auf den fetten Servern in der Zentrale.

    Es geht hier nicht nur um Konten. Es geht auch um Terabytes an Projektdaten, Modelle, Prüfstandsergebnisse etc.
    Das alles über eine dünne Leitung direkt in der Zentrale zu speichern ist nicht möglich.

    > > Warum lokaler Admin?
    > > In dem genannten Beispiel ist die weltweite IT 50 Mann stark, bei 30
    > > Standorten. Und du willst an jedem Standort einen Admin haben?
    > > Realitätsfern. Vorallem weil es auch ohne wunderbar funktioniert.
    >
    > Wenn das Netzwerk in einem Standort ausfällt? Wenn generell dort mal was
    > ausfällt? Keinen Admin haben? Du bist mutig.

    Funktioniert seit Jahren ohne Probleme. Hardware mit Vor-Ort-Service kaufen ist günstiger als 35 weitere Admins einzustellen.

    > > Hm. Wir haben aktuell 7 dicke VMware Hosts, die allesamt am Pöller sind.
    > > Dazu kommen noch ca. 35 physikalische Server (und zwei dicke
    > > Rechencluster).
    > >
    > > Das sind ganz normale Zahlen für ein solches Unternehmen. Und das willst
    > du
    > > über zwei dicke Server abwickeln? Ist ja süß.
    >
    > Ich weiß ja nicht, was die genau machen. Bisher war immer die Rede von
    > "Hilfe, wir haben zu viel Rechenkapazität".

    Zuviel Rechenkapazität hat man eher wenn man ohne Virtualisierung arbeitet :-)

    > Natürlich kann ich noch mehr Maschinen hinterklemmen.
    >
    > > Du musst bedenken, dass ziemlich viel zentral abgefragt wird und
    > speziell
    > > nach Indien und Afrika nur dünne Leitungen (<4 Mbit/s) liegen. Caches
    > haben
    > > wir natürlich, aber reicht dennoch nicht.
    >
    > Ja, deswegen habe ich an die lokalen Server gedacht. Und wo ein Server ist,
    > sollte auch ein Admin sein. Eigentlich sollte schon da, wo nur ein paar
    > Computer rumstehen, schon ein Admin sein. Und wenn es nur um "starten Sie
    > die Maschine neu" geht.

    S.o.

    > > Wer sprach von Datensicherheit? 2 physikalische Hosts für die VMs und du
    > > hast eine Ausfallsicherheit, falls ein Host hops geht. Bei
    > physikalischen
    > > Servern ist der Server erstmal tot.
    > > Backup wird natürlich trotzdem gemacht.
    >
    > Ach so meinst du das. Ich dachte gerade daran, dass du die Backups auf der
    > gleichen physikalischen Maschine, nur andere VM machen willst.

    Nein, natürlich nicht. :-)

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

    Autor: gaym0r 31.03.16 - 11:34

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Isotopp schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Linuxschaden schrieb:
    > > > Cloud braucht keine Sau, Virtualisierung braucht keine Sau.
    > >
    > > Du hast gut 10 Jahre Hardware-Entwicklung verpaßt.
    >
    > Nein, die meisten können durch Hardware Schludrigkeit kompensieren.
    >
    > > Ich habe es Dir einmal aufgemalt
    >
    > Ohne Not! Das alles kann ich auch ohne VM haben. Immer noch auf der
    > gleichen Maschine. Wozu?!

    Du willst also 20 verschiedene Dienste auf einem Server ausführen?

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

    Autor: gaym0r 31.03.16 - 11:37

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > ... in meinem Weltbild kann ich meinem VLAN-fähigem Switch sagen, dass er
    > bestimmte Ports für bestimmte VLANs reserviert. Dann brauche ich kein Tag.

    Und wie kriegst du das VLAN dann vernünftig über alle deine Tausende Switches verteilt?

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

    Autor: gaym0r 31.03.16 - 11:39

    derdiedas schrieb:
    --------------------------------------------------------------------------------
    > Nicht alles was in einer virtuellen Umgebung läuft ist für außerhalb
    > gedacht, sonder inter Server Kommunikation (Cluster für den AppServer,
    > Cluster für die Datenbank, Cluster für das SAN usw... usw... usw...)

    Dann hab ich dich falsch verstanden. In meinen Clustern verlässt kein Datenpaket das Cluster an sich...

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

Neues Thema


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. SAP Treasury Consultant / Business Analyst (m/w/d)
    Allianz Technology SE, Stuttgart
  2. Junior Network Engineer - Connectivity (m/w/d)
    STRABAG BRVZ GMBH & CO.KG, Stuttgart, Köln
  3. Sachbearbeiter (m/w/d) Digitalisierung
    Stadt Korntal-Münchingen, Korntal-Münchingen
  4. Spezialistin Supportmanagement (m/w/d)
    Stadtwerke München GmbH, München

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de