VoIP - Telephonie und Wirrtualisierung: 1. Prolog

Dieses Thema im Forum "Telekommunikation Allgemein" wurde erstellt von Koppelfeld, 4. Februar 2021.

  1. Koppelfeld

    Koppelfeld Die Wahrheit ist den Menschen zumutbar.

    Beiträge:
    993
    Zustimmungen:
    58
    Ein Interessent hat einen technischen Artikel aus einem "VMWare - Forum" gefunden, "Einstellung der Latenzempfindlichkeit bei VMWare x.y.z". Nachdem dies offenbar ein Thema ist, sorgt es sich darum, ob er tatsächlich eine IP-basierte Telephonanlage innerhalb einer virtuellen Maschine laufenlassen möchte.

    Antwort in Kurzform:
    Ja, man kann das tun.

    Begründung in Kurzform:
    Die eigentliche Gesprächsvermittlung findet bei gut konfigurierten TK-Anlagen außerhalb statt, sprich, zwischen den Netzwerkswitchen und den Telephonen.
    Die Telephone müssen mit variablen "Latenzen" (i.e. Verzögerungszeiten) zwischen zwei Teilnehmern rechnen und speichern deshalb 200 bis 600 Millisekunden in einem "Dejitterbuffer" vor. Etwa so, wie das auch bei einer medizinischen Infusion gemacht wird: Ein kleines "Zwischenreservoir" sorgt dafür, daß man den Infusionsbehälter wechseln kann, ohne daß der infundierte Volumenstrom schwankt.

    Dank des Dejitterbuffers und dank der Erfindung des Ethernet-Switches kann man generell auch Plagen wie "VMWare" einsetzen und von deren administartiven Vorteilen profitieren.

    Die lange Antwort ist: LANG.
    Für den Fall, daß es Menschen gibt, die das Thema interessiert, fasse ich unsere Erfahrungen einmal in den nachfolgenden Beiträgen zusammen.
     
  2.  
  3. Koppelfeld

    Koppelfeld Die Wahrheit ist den Menschen zumutbar.

    Beiträge:
    993
    Zustimmungen:
    58
    Meine Kollegen schimpfen ja immer, "wie kannst Du vom Namen oder vom Begriff auf Qualität oder Wesen schließen ?" Und ich sage: Das geht ganz einfach. Nachzulesen im "tractatus logico-philosophocus" von Ludwig Wittgenstein: "Was gesagt werden kann, kann auch klar gesagt werden".

    Wenn in einem offiziellen Herstellerforum von "Latenzempfindlichkeit" einer Plattform die Rede ist, dann weiß ich: Hier hat ein dümmlicher Jungspund wieder einen Begriff durch den "Google-Übersetzer" gequetscht.
    Neuerdings, oder zeitgemäßer, "am Ende des Tages", werden Netzwerkgeräte "provisioniert", sie erhalten also für ihre "Vermittlungsleistung" eine Prämie, eine "Provision". Oder vielleicht doch nicht? Englisch kann ja schließlich jeder, und insofern muß man auch gar nicht nachschauen, daß 'to provision' u.a. "Vorbereitung" oder "Beistellung" heißt. Netzwerkgeräte werden also mithilfe einer beigestellten Konfiguration "vorbereitet" -- aber nicht "provisioniert". Unsere Degeneration Y aber "schlaut sich gern auf Twitter auf" und kein Dünnschiß ist zu dämlich, daß nicht einer vom anderen abschreibt. Man suche allein hier im Forum nach "Provisionierung", da wird einem kotzig schlecht. Nochmals weitaus schlimmer ist es mit "Bandbreite", die mit "Leitungsdurchsatz in Bit/Sekunde" genau NIX zu tun hat. Eine "Bandbreite" bezeichnet eine Frequenzdifferenz. Gigabit-Ethernet ist rechnerisch zehn Mal schneller als Fast Ethernet, aber beide arbeiten mit einer Bandbreite von etwa 33 MHz.

    Wir haben den Fehler gemacht, von der klaren lateinischen Wissenschaftssprache wegzugehen zu einer besonders degenerativen Art des 'modern Esperanto', zusammendeliriert aus allen möglichen "Kulturen". Krass, ey. Information wird zur Beliebigkeit. Und jeder kann demokratisch mitlabern.

    Kommen wir zur "Latenzempfindlichkeit" einer VMWare-Plattform. Im Original sollte wohl gestanden haben, "Adjustment for latency-critical VM guests", "Einstellungen für Anwendungen mit kritischen Latenzanforderungen". DANN würde ein Schuh draus: Nicht die "VMWare" ist "latenzempfndlich", sondern die darauf betriebene Anwendung ist "kritisch" in Bezug auf ihr Laufzeitverhalten.

    "Ratgeber", die schon mit einer verschwurbelten Fragestellung anfangen, ohne sie überhaupt erstmal zu klären, kann man gleich in die Tonne treten und die "Produkte", über die dermaßen geschrieben wird, gleich auch.

    Die Frage ist: "Kann ich 'Echtzeitkommunikation' bedenkenlos auf einer virtuellen Maschine laufen lassen ?"

    Dem wollen wir im folgenden einmal nachgehen.
     
  4. Koppelfeld

    Koppelfeld Die Wahrheit ist den Menschen zumutbar.

    Beiträge:
    993
    Zustimmungen:
    58
    Es hat schon seinen Grund, weshalb ich mich so lange mit der Sprache aufgehalten habe.
    Sprachkommunikation basiert bei VoIP zumeist auf "RTP", dem "Realtime Transport Protocol".

    Bei uns gerne mit "Echtzeit" übersetzt. Und der moderne "Digital Naive" weiß: "Das ist besonders schnell".

    Einen Scheiß weiß er.

    "Echtzeit", Plesiochronizotät in der ISDN - PDH, das WAR EINMAL. Tatsächlich war der ISDN-Takt früher bundesweit synchron. Wegen der Laufzeitabweichungen sprach man korrekterweise von einer "Plesiochronen Digitalen Hierarchie". Und weil ein elektrisches Signal in einer Millisekunde 300 Km zurücklegt, betrug die durchschnittliche Zeitabweichung von der Mitte der Bundesrepublik aus in etwa eine Millisekunde.

    Eine VoIP - Verbindung unterliegt typischerweise einer einfachen Signallaufzeit von etwa 30 (!) ms. Von wegen "Echtzeit". In 30 ms "schafft" sogar ein Intel-Prozessor 45 Millionen Instruktionen, mit einer ordentlichen Serverarchitektur wie POWER erzielt man locker 100 Millionen.

    Es ist also gar nicht nötig, daß eine softwarebasierende VoIP - TK-Anlage "echtzeitfähig" ist.

    "Echtzeit" oder "real time" bedeutet übrigens GENAU NICHT "schnell", sondern "deterministisch". Sprich:
    Die Anwendung kann langsam sein wie ein Braunkohlebagger, aber sie muß garantieren, ihr Pensum mindestens bis zum Zeitpunkt x geschafft zu haben.

    Genau das aber kann eine virtuelle Maschine auf einer gammeligen "VMWare" niemals garantieren.

    Denn man muß immer damit rechnen,

    - daß die CPU stockt, weil der VM-Gast seine Zeitscheibe verliert
    - der I/O stockt, weil andere Gäste diesen stark beanspruchen
    - die Netzwerkschnittstelle hängt.

    Intelligente Betriebssysteme "kennen" ihre Anwendungen und "sehen":
    - "Oh, dies ist der 'common bufferpool' des IP-Stacks, und wenn er noch so groß ist, dann lagere ich den NIEMALS auf die Massenspeicher aus"
    - "Es sei denn, ich heiße 'Windows NT'" (Was haben wir gelacht damals. Die Trendlemminge kauften dennoch wie bekloppt)

    - "Oh, diese kritische Interruptroutine für die Netzwerkkarte braucht unbedingte Priorität"
    - "Dieser Schwachsinn rechnet eine EU-Intrastat-Liste zusammen. Letzte Priorität, die Zahlen sind sowieso alle getürkt"

    Nun stülpt sich "VMWare" über die kritschen Ressourcen wie die fette, alte Mutti "Europa" über die Mitgledsstaaten. Frau von der Laien dirigiert die Zuteilung. Und das klappt grandios, zum Beispiel beim Impf-
    oh -- etwa nicht ?
    Wie das wohl kommt -- damit konnte KEINER RECHNEN ?
    Und die lächerlichen 50.000 Tote, die infolge der Schluderei dabei auf der Strecke bleiben, interessieren niemanden, und schon gar nicht die EU-Kommission, denen die Bedürfnisse derer, die sie mandatiert haben, am Arsch vorbeigeht.

    So ungefähr wie sich Frau von der Laien für hre Bürger interessiert, s interessiert sich auch der VMWare-Hypervisor für seine Gäste. Und entsprechend dem SED-Credo, "Lieber für alle alles gleich Scheiße",
    macht VMWare jede Anwendung zum Mittelmaß.

    Schließen möchte ich mit einem Zitat von Rupert Lay,

    Das Mittelmaß als Feind der Weisheit:

    "Nicht der Bösewicht ist der Schurke, sondern das Mittelmaß, wenn man die politischen, ökonomischen, sozialen und kulturellen Dramen unserer Zeit betrachtet oder gar aufzuzeichnen versucht. Schon Platons Vermutung, dass die Demokratie die Herrschaft des Mittelmaßes bedeutet, hätte uns nach der Einführung demokratischer Systeme in Europa nach 1848 etwas vorsichtiger mit dieser Herrschaftsform umgehen lassen müssen. Nun, das haben wir versäumt – und so beherrschen uns in Politik und Wirtschaft, im sozialen (etwa auch in den Gewerkschaften) und im Kulturellen (etwa in den Kirchen) das Mittelmaß."
     
  5. Koppelfeld

    Koppelfeld Die Wahrheit ist den Menschen zumutbar.

    Beiträge:
    993
    Zustimmungen:
    58
    Eine besonders amüsante Szene aus "Rossini", ein Arzt untersucht eine befreundete Patientin, von der er etwas "mehr" will und balzt mit Komplimenten, die nach hinten losgehen. Die Angebetete gibt passend heraus:

    "Belästige mich nicht mit Deinen Altenpflegerphantasieen, Siggi, sondern gib mir endlich 'was, damit ich wieder scheißen kann"

    Moderne Informatiker fokussieren immer wieder auf "den Prozessor", allein:

    Der beste Prozessor nützt nix, wenn man seine Internet-Pakete nicht loswird.

    Der PC-Prolet setzte immer darauf, alles von der zentralen Rechnereinheit machen zu lassen, erinnern wir uns an die *ACHTUNG, TRIGGERWARNUNG! NAUSEA-GEFAHR* infame "Fritz-Card":
    Der eigentliche "ISDN-Controller" war der "PC" selbst, und damit jener diese Aufgabe erfüllen konnte, wurde 250 Mal pro Sekunde ein Interrupt losgetreten. Wenn die unterhalb jeder Schamgrenze "konzipierte" Fritz-Krätze nicht in Betrieb war, wurde der angelaufene Interrupt zwar relativ früh mit IRET beendet.
    Doch jeder angelaufene Interrupt, jeder verdammte Taskwechsel sorgt dafür, daß der Instruktionscache invalidiert wird. Nach Rückkehr aus einem Service-Interrupt muß die von der Fritz-Krätze gestörte Anwendung ihre Instruktionen aus dem vergleichsweise langsamen Hauptspeicher neu laden.

    Es gab aber auch immer Menschen, die ein Rechnersystem nicht als Spielzeug, sondern als Werkzeug begriffen. Und die orientierten sich am wirklichen Leben und lagerten spezialisierte Arbeiten an spezialisierte Controller aus.
    Netzwerktechnik ist ein verpackungsintensives Geschäft, VoIP - Pakete beinhalten typischerweise nur 20 Millisekunden. Pro Sekunde müssen also für eine einzige bidirektionale VoIP-Verbindung 100 Pakete geschnürt werden, allerdings nach dem Prinzip der "Russischen Puppe": Von innen nach außen wäre das das RTP-Paket, UDP-Paket, das IP-Paket und das Ethernet-Paket. Und jedes Paket muß sehr aufwendig adressiert und mit allen möglichen Informationen versorgt werden.
    400 verschachtelte Pakete pro Sekunde für ein einziges Telephonat ... man kann sich leicht denken, daß bei einer großen TK-Anlage einiges zusammenkommt.
    Früher gab es beispielweise bei der DATEV Versandstraßen, an denen jede Menge Gastarbeiterinnen saßen und auf Teufel komm' 'raus Pakete packten, die dann per eigenem Kurierdienst bundesweit täglich an fast alle Steuerberater ausgeliefert wurden. Nun haben die Gastarbeiterinnen heute alle ganz wichtige Sachen studiert, nennen sich Meli Kijak, Ferda Ataman, Margarete Stokowski oder Hasanin Kazim und erklären uns in der "taz", im "Spiegel" oder "auf Twitter" unsere kleine Welt.

    Also mußte etwas anderes her: Ein kleiner "Verpackungsspezialist" (m/w/d) sitzt als eigenständiger "Unterserver" in der Maschine und nimmt der CPU die ganze Ein- und Auspackerei ab. Der Zentalrechner sagt dem Ethernet-Controller, "Ich habe hier Daten an dieser Speicheradresse, es ist ein Folgepaket, Zieladresse hast Du also schon, informiere mich, wenn die Gegenstelle den Krempel erhalten hat".
    Der Controller hat sogar die Lizenz, direkt auf den Hauptspeicher zuzugreifen, sodaß die CPU nicht selber wild durch die Gegend herumkopieren muß -- denn auch das würde den CPU-Cache invalidieren. Man spricht auch gern, sehr treffend, von "trashing".

    Und nun haben wir ein Problem, wenn wir "wirrtualisieren":
    In eine virtuelle Maschine kann ich ganz schlecht einen physischen Controller einbauen !
    Schlimmer noch: Eine wirrtuelle Netzwerkkarte kann man wiederum nirgendwo physisch einstecken. Wir brauchen also, betcha didn't figure out, einen wirrtuellen Switch ! Und dreimal dürft Ihr raten, wer die Drecksarbeit erledigen muß -- die Wald- und Wiesen - CPU !

    Und so ist die Kacke ordentlich am dampfen:

    - Die CPU muß alles wieder selbst erledigen,
    - dadurch wird der Nutzen des schönen, großen Caches partiell ausgehebelt.
    - Jetzt wird's schmutzig: Der "vrtuelle Switch" wird durchlaufen und konsumiert weitere CPU-Leistung.

    Seht Euch das unten angehängte Bildchen an: Auf der linken Seite sieht man den beschwerlichen Weg eines IP-Paketes "durch die Instanzen". Dabei sollten auch zusätzlich die "teuren" Hypervisor- / Kernel- / Userspaceübergänge (vier Stück an der Zahl) Beachtung finden.


    Wir sprechen hier allerdings von albernem, "zeitgemäßen" Dilettantengefrickel wie z.B. "VMalware".

    "Richtige" IT, das nur am Rande, unterliegt nicht solchen Einschränkungen:
    - warum soll ich mir eine virtuelle "Claudia Roth" anschauen, wenn ich eine "Martina Gedeck" haben kann ?
    - sprich, man nimmt dazu eine servergeeignete Prozessorarchtektur her und keinen Intel-PC.
    - seht euch die rechte Hälfte des Bildchens an: So macht es der Profi. Die virtuelle Maschine kann wieder an "echte" Hardware delegieren.
    - Profiis stellen auch echten Block-I/O zur Verfügung, anstatt "virtuelle Festplatten" in ein gammeliges NTFS-Filesystem zu kotzen. Alleine über diesen Schwachsinn könnte man fünf Artikel schreiben.


    Zusammenfassend: Wenn man Formel 1 fahren will, dann braucht man einen Rennwagen und keinen "Golf GTI". Und auch einen ordentlichen Mechaniker.

    VoIP - Anwendungen aber sind nicht so anspruchsvoll, wie man denkt.

    Die hohe Leistunsfähigkeit moderner PC-Prozessoren kaschiert die hanebüchenen Zustände quasi wie ein potemkinsches Dorf.

    Man darf sich allerdings nicht wirklich wundern, wenn nicht einmal interne Faxe richtig funktionieren, aber dazu später mehr.
     

    Anhänge:

  6. Koppelfeld

    Koppelfeld Die Wahrheit ist den Menschen zumutbar.

    Beiträge:
    993
    Zustimmungen:
    58
    Wer keine Notfallszenarien geplant hat, verliert. Mit Hochverfügbarkeit im Quadrat.


    Ein Kunde betreibt quasi als Ausgangspunkt seiner Fertigung ein großes TRUMPF - Bearbeitungszentrum. Unter "Windows NT 4.0", nebenher, aber das ist im deutschen Fertigungsmaschinenbau nichts ungewöhnliches. Auch nicht bei den Medizingeräten.

    Fällt das Bearbeitungszentrum aus, steht nach kürzester Zeit der ganze Betrieb.

    Selbstverständlich ist die hochkomplexe Maschine extrem zuverlässig - nur leider die Software nicht.

    Es sind mehrere "Softwares" unter "Windows", der Kunde entschied sich für eine "hochverfügbare Wirrtualisierungslösung".


    Es kommt der Tag, an dem der Rechner, auf dem das Produktionsensemble läuft, ausfällt.

    Ich werde dazugerufen, die Fernbetreuer von TRUMPF kommen nicht mehr auf die Maschine.

    • Die automatische Umschaltung auf das Sekundärsystem hat leidlich funktioniert, nun starten aber die Windows-Betriebssysteme nicht mehr mit dem Verweis auf eine Lizenzverletzung.
    • Auch die Softwarelizenzen, die sich beim Umschalttest wohl noch in der Karenzzeit befanden, wurden nicht akzeptiert. Hinterher wurde behauptet, es sei einem "VMWare-Update" geschuldet.
    • Wir müssen also nolens volens die Produktivmaschine wieder auf Vordermann bringen.
    • Für so etwas möchte man gern eine Konsole. Ich will am KVM oder vor Ort am lokalen Monitor den Bluescreen des verreckten VM-Gastes sehen. Zu meiner Verblüffung höre ich: "Das geht nicht".
    • O.K., dann kann ich wenigstens mit einer Brause auf den VMWare-Server?
    • ABER JA! Aber nur zum herunterladen eines "Vschmier-Clients".
    • Den gibt es aber nur, wer hätte das gedacht, für "Windows"...
    • An ein "Windows-Notebook" ist ja dranzukommen, ich lade den Installer für den Vschmier-Client vom Server herunter und
    • *päng*, verreckt die Installationsroutine. Denn, eine Stunde später aus der "Microsoft Knowledgebase" wie ein Goldsucher am Klondike herausgesiebt: Diese veraltete Version des Vschmier-Clients würde einige "DLLs" ersetzen, das sei aber mit dem aktuellen Update-Stand des Notebooks unverträglich...
    • Ich bin doch nicht blöd ... Ein "frischer" Vschmier-Client ist in Stundenschnelle installiert und nun brauche ich mich nur noch mit meinem Client zu verbinden ...
    • aber jetzt meckert die "Vschmier": "Hey, mit SO einem alten Server verbinde ich mich nicht ! Da muß ein SICHERHEITSUPDATE her !
    • Das Sicherheitsupdate kann ich aber nur mit dem Vschmier-Client installieren.
    Das nennt man dann wohl "Deadlock". Der Deadlock ist der häßliche kleine Bruder des Absturzes.
    "Irgendwie" haben wir Zugriff auf den Server bekommen. Aber drei Stunden waren beim Teufel.

    Zeigt sich immer wieder: "Gut gemeint" ist nicht immer "gut gemacht". Denn wenn ein Verschlüsselungstrojaner "virtuelle Festplatten" anknabbert, ist auch in schöner Regelmäßigkeit die Sicherung im Eimer.
    Da hilft dann nur: Vom Band zurücksichern.

    Im beschriebenen Fall war das Resultat ein einwöchiger Produktionsausfall "am Stück" und jede Menge Nacharbeit.

    Da war es schon ganz gut, daß wenigstens TK und ERP auf je einem Extra-Blade liefen, denen die Ransomware nichts anhaben konnte.

    Aktuelle x86-Virtualisierer sind im Notfall gefügiger, aber das Überkomplexitätsproblem bleibt bestehen. Ich sehe es als kritisch an, WINTEL mit dem "Internet" zu verbinden. Ich sehe auch nirgendwo eine ordentliche Unterstützung für Bandstationen, welche m.E. das einzig robuste Datensicherungsmedium darstellen, ibs. deshalb, weil alle gesicherten Dateien sauber serialisiert werden. Bei einem LTO-Band garantieren die Hersteller Lesbarkeit nach 30 Jahren.
    Es gibt LTOs auch als WORM, sprich, sie lassen sich nach dem Beschreiben nicht mehr ändern.
    Auf diese Weise kann man leicht seiner Archivierungspflicht nachkommen.


    WENN WIRRTUALISIERUNG, dann wären also folgende Kriterien elementar wichtig:
    • kein Internetzugriff auf die / durch die Virtualisierungsplattform selbst
    • kein "Intel-Schadcode" darf ausführbar sein --> komplett andere Rechnerarchitektur
    • "direkter" Zugriff auf hardwareunterstützte Netzwerkkarten, siehe vorigen Beitrag
    • Block I/O, sprich, dedizierte, unfragmentierte Datenträgerbereiche zum unmittelbaren Zugriff durch den VM-Gast
    • Lokale, redundante Datenträger für Elementarfunktionen wie Telephonanlage
    • Bandsicherung
    • automatisierte Komplettwiederherstellung vom Band
    • konservative Auslegung der Hardware auf geringe Temperaturen (10 K Temperaturerhöhung halbiert die Lebenszeit)
    • Zuweisung spezieller PCIe-Karten direkt an einzelne VM-Gäste
    • VIEL Hauptspeicher, kein Overcommitment
    • "Concurrent Maintenance", sprich, Austausch von Komponenten im laufenden Betrieb, ohne alle Anwendungen herunterzufahren
    • Keine SATA-Platten, sondern schnelle SAS, ggfs. mit SSDs ergänzt
    • Storage Controller mit großem, batteriegepufferten Schreibcache
    • anständige unterbrechungsfreie Stromversorgung
    • Fernsteuerbare Systemkonsole zum schnellen Eingreifen im Störungsfall
    • ordentliche Ethernetanbindung, redundant mit Linkaggregation
    • energiesparende Konzeption
    Eine solche Plattform fängt bei 50.000,-- an.
    Es sei denn, man kann mit dem "Vorgängermodell" leben, investiert ein Zehntel und genießt das beruhigende Gefühl der Sicherheit.

    Mit einer solchen Maschine kann man, auch unter Last, hausintern 20-seitige hochauflösenden Faxe mit 33.600 bit/s versenden.


    Mit einer Telephonanlage auf einer der marktüblichen Plattformen hätte ich eher meine Schwierigkeiten.

    Fakt ist: Die alten SIEMENS "HIPATH" halten 20 Jahre und länger, laufen unprätentiös und zuverlässig durch. Das muß eine Wirrtualisierungsplattform erst einmal bieten.

    Die Erfahrung lehrt: EDV kann schon 'mal ausfallen, daran sind wir ja mittlerweile alle durch Microsoft und "PC-Systemhäuser" gewohnt. Aber Anwender werden fuchsteufelswild, wenn sie nicht telephonieren können.
    Der beste Weg, unmittelbare und gleichzeitige persönliche Bekanntschaft mit Firmeninhabern, Chef, Prokurist, Abteilungsleitern und allen Sekretärinnen zu machen ist, die Telephonanlage außerbetriebzusetzen.

    BTDT.
     
  7. telthies

    telthies Urgestein

    Beiträge:
    8.407
    Zustimmungen:
    227
    Wenn Du mal Siemens lobst, müssen die Schmerzmittel ja wirklich recht heftig sein. Dennoch: strebst Du nach einer Schreibsperre, oder was soll dieses für jedes Kapitel eines Threads einen separaten Beitrag anfangen ?
    Ich dachte, mich klar ausgedrückt zu haben: Weiterführung des Stranges in Teil 3 und keine weiteren.
     
  8. tobiasr

    tobiasr Urgestein

    Beiträge:
    1.108
    Zustimmungen:
    112
    So. Themen zusammengefügt. Für eine Überschrift diese bitte erneut IM Beitrag einfügen. Antworten bitte ausschließlich durch Koppelfeld.
     
    telthies gefällt das.
  9. Koppelfeld

    Koppelfeld Die Wahrheit ist den Menschen zumutbar.

    Beiträge:
    993
    Zustimmungen:
    58
    Danke. Hallo Thies, seit über einem Monat versuche ich es OHNE heftige Schmerzmittel, aber dafür sind die Schmerzen umso heftiger.
    Bitte um Entschuldigung für die Zusatzarbeit.
    Unterdessen habe ich festgestellt: Das Thema ist so vielschichtig, daß man es im Rahmen eines Forums gar nicht wirklich ausreichend behandeln kann.
    Ich setze jetzt noch eine Zusammenfassung hier dran und dann lassen wir es gut sein.


    Also:

    Was nun wirklich tun ?

    Vielleicht noch eine, dann aber wirklich letzte "Vorbemerkung":

    Zusammen mit dem Benutzer "tobiasr" haben wir auf dessen Anregung hin ein "SNOM" - Telephon einem Kunden zur Verfügung gestellt. "tobiasr" wiederum war inspiriert von der posititiven Meinung von "retrofreak".
    Ich persönlich kenne und vor allem schätze beide, sie stecken tief in der Technik, kennen wichtige Grundlagen und bilden sich ein fundiertes Urteil aufgrund ihrer Beobachtungen.

    Das Dumme ist nur: Der Köder muß dem Fisch schmecken und nicht dem Angler.

    Und da muß ich sagen: Die SNOM - Modelle zelebrieren die "Berliner Lebensart" auf genau die tolldreiste Art, wie man es seit Jahrzehnten von diesen krakeelenden Lauscheppern aus dem "Bundeshauptslum" (Don Alphonso) gewohnt ist.

    Das billige Plastik, das vortäuscht, Aluminium zu sein. Die Firmware, die "XML" benötigt zur Konfiguration. Die grottenschlechte Qualität der Sprechgarnitur (eine mußten wir schon umtauschen). Vor allem aber: Die "Komjuniti", die überall talibanesk propagiert: "Du WILLST Snom". Wenn ich das schon höre, dann weiß ich Bescheid.

    Warum erwähne ich das?
    Mit ENTSETZEN haben "tobiasr" und ich nämlich festgestellt, daß unser "Smömchen", wie es die "Starface"-Fanboys liebevoll nennen, beim Start erstmal intensiv nach Hause telephoniert. Ohne uns zu fragen.
    Die Yealink-"Chinakracher" machen das auch, aber noch subtiler:
    "Cloud-Anbieter" registrieren ihre Geräte beim Hersteller. Sehr oft scheitern, aus sehr einfachen Gründen, die angepriesenen "Cloud-Projekte" kläglich. Deswegen kann man auch oft "Sonderposten" an "Demo-Geräten" kaufen, die vllt. drei Wochen in Benutzung waren - mit minimalen Gebrauchsspuren und zum halben Preis.
    Wenn man diesen Geräten jetzt Internet "gönnt", wählen sie sich ein und konfigurieren das Gerät so um, daß es sich nur noch mit dem "Cloud-Anbieter" verwenden läßt.
    FREIHEIT, die ich meine, das hätten sich die Grünen nicht infamer ausdenken können.
    Man kann dieses Verhalten auch wieder ändern, indem man den Urlader neu flasht, aber das ist nix mehr, was ein Anwender tun sollte.

    Was also tun?
    Obwohl es ein Paradoxon ist, kann ich nur empfehlen, Internet-Telephone auf keinen Fall ins Internet zu lassen. Gerne ins LAN, ja. Aber Kontakt bitte nur zur Telephonanlage und ein Default-Gateway brauchen sie auch nicht. Auf die Art bekommt man übrigena auch ein "Windows" sicher.
    Das heißt natürlich, daß die TK-Anlage "bridgen" muß. Konsequenz: RTP-Datenstrom ein- und ausgehend über die TK-Anlage. Das heißt auch, daß die TK-Anlage die Firmware bereitstellen muß, aber das tut eine seriöse TK-Anlage ja auch.

    Dazu sollte die Netzwerkanbindung schon "ordentlich" sein, sprich: Mindestens zwei Gigabit-Interfaces, besser noch drei:
    • Interface mit öffentlicher IP, sodaß die TK-Anlage "von außen" erreichbar ist. Denn das ist das Wesen einer TK-Anlage, und die "NATterei" saugt Hamster durch Strohhalme. Das Faß machen wir aber nicht auch noch auf. Auf jeden Fall gehört jetzt eine Firewall (zu deutsch: Ein Paketfilter) davor, der z.B. den Traffic auf diesem Interface auf den Voice-Provider beschränkt.
    • Alternativ hierzu: Dediziertes Interface zum Session Border Gateway des VoIP-Providers. So hat selbst die "T-Systems" erkannt, wie beschissen das Telekom-Angebot ist und stellt ihren Geschäftskunden einen solchen SBC hin, beispielsweise von LANCOM. Der registriert den SIP-Trunk und reicht ihn dann an die TK-Anlage weiter. Es bietet sich an, das über ein separates Netz zu tun. In beiden Fällen kann der SBC resp. der Paketfilter ein einfaches "QoS" auf der WAN-Strecke ermöglichen. Auch dieses Faß machen wir jetzt nicht auf.
    • Interface in das "Voice" - LAN, welches gern als VLAN ausgeführt sein kann. Damit haben wir die Telephoniegeäte schön sauber von den anderen getrennt. Und JA, moderne VoIP - Telephone ermöglichen es, am "Internet"-Port zwei VLANs aufzunehmen, über das VoIP-VLAN zu telephonieren und das Abteilungs-VLAN auf den "PC" - Port zu legen. Dann kann man prima ein Telephon zwischen PC und LAN-Steckdose stecken. Wenn jetzt der Switch noch "PoE" kann, sind wir fast da, wo wir mit UP0 vor 25 Jahren schon einmal waren. DAS ist Fortschritt, oder?
    • Optional: Interface in das Abteilungs-LAN. Beispielsweise für CTI, für Übertragung der Anrufer-Bilder, zur Kommunikation mit Türstationen und Zeitdatenerfassung etc. pp.. Über diese Verbindung kann man auch qua VPN in Niederlassungen routen.
    Wir sehen: Es kommt schon etwas zusammen an Netzwerk. Es wäre schön, wenn man für zeitlich koinzidenten "eingehenden" und "ausgehenden" Traffic unterschiedliche Interfaces hätte. Das empfiehlt sich auch aus Gründen der Sicherheit und Übersichtlichkeit.


    UND JETZT DER VERSUCH EINER ZUSAMMENFASSUNG:

    Ja, man KANN versuchen, eine TK-Anlage auf einer gepflegten Virtualisierungsplattform zu betreiben.
    "Einfach" ist es nicht, Telefaxe sind der Prüfstein und die Einrichtung ist nicht unbedingt trivial.
    Es gibt "modernere" Virtualisierungsplattformen, die die von mir benannten Schwachstellen zu umgehen versuchen, indem sie Komplexität mit Komplexität bekämpfen, vielleicht schreibt "retrofreak" einmal etwas dazu.

    Um es aber klar zu sagen, wir haben Kunden, die mit einer "virtualisierten" TK-Anlage zufrieden sind.

    Persönlich sehe ich die Berechtigung einer wirrtuellen Lösung eher als Backup-System, das man einfach anwirft, wenn eine kleine Hardware-Appliance defekt gegangen ist.


    Was würde ich nehmen ?

    Ganz klar:
    a) Budget etwa 2.200,--: Das würde bei mir eine kleine IBM POWER 8, mit 2 Höheneinheiten, 2 CPU, 12 Platteneinschüben, gebraucht gekauft. Die nähme ich dann mit "echter" Virtualisierung (IBM POWER VM) und würde dann auch noch alles darauf laufenlassen, was direkt mit dem "Internet" in Berührung kommt.
    Webproxy, Webserver, Reverse Proxy, Zugangssoftware - alles, was man so ansammelt und nicht gern ans Internet läßt.
    Denn kein "Virus" oder "Trojaner" wäre unter POWER lauffähig. Außerdem ist das Maschinchen intuitiv bedienbar und verfügt über Redundanz an allen kritischen Komponenten. Lüfterwechsel ? Im laufenden Betrieb.

    b) Budget etwa 500,--
    Dann nähne ich ein Stück Hardware, IBM POWER 7, gebraucht für 400,--. Ohne Wirrtualisierung, die TK-Anklage würde ich 'bare metal' installieren. Läuft so unprätentiös und zuverlässig wie die alten SIEMENS-Kisten.

    c) Budget etwa 1.000,--
    In diesem Falle kann es auch ein kleiner, INTEL - basierter "Supermicro" sein, vorzugsweise ein Rack-Gerät. Ein drittes Gigabit-Interface läßt sich preisgünstig nachrüsten.

    Davon absehen würde ich, ausrangierte Uralt-Server zu "recyclen". Der Stromverbrauch (und der Aufwand zum Wegkühlen) macht die Einsparung oft zunichte.


    Wenn ich die eine oder andere Frage habe beantworten können oder zumindest einen Denkanstoß geben konnte, dann würde ich mich freuen.
     
    telthies gefällt das.
  10. telthies

    telthies Urgestein

    Beiträge:
    8.407
    Zustimmungen:
    227
    ??? auch wenn ich nicht erwarte, daß sich hier die Mitdiskutanten aller Länder träfen ...