MPLS oder LANCOM VPN

[5624]

Bei MPLS musst du bedenken, dass du an deinen Anbieter mehr oder weniger gebunden bist. Im Gegenzug hast du QoS. Eine garantierte Bandbreite hast du nicht, weil dein Engpass die Zentrale ist. Für eine garantierte Bandbreite, bräuchstest du hier einen Anschluss, der eine Bandbreite in Höhe der Summe aller Filialanschlüsse hat. Eine Kommunikation zwischen den Filialen wird es sicher nicht geben.

Beim VPN-Overlay-Netz hast du die freie Auswahl des Anbieters. Wenn Provider A nichts anbieten kann oder das Angebot nicht tragbar wäre, nimmt man halt Anbieter B. Ich hab z.B. eine Filiale, bei der die Telekom selbst DSL768 nicht stabil anbieten kann. Aber beim Aufbau des Centers wurde in jede Mietfläche eine Glasfaser eingezogen.

Du schreibst jetzt von Internetanbindungen der Zentrale. Zwei verschiedene Provider? Wenn ja, verlierst du durch das MPLS an Redundanz. Hier müssen ja beide Leitungen vom gleichen Provider kommen und die landen mit hoher Wahrscheinlichkeit am Ende im gleichen Verteilerknoten.

Wie ist dein VoIP realisiert? Haben die Filialen eine Nummer aus dem Ortsnetz und du willst noch eine zusätzliche Vernetzung aufbauen oder werden alle Telefonanschlüsse über die Zentrale bereitgestellt?

Die 150MBit werden wohl reichen. Ich habe 80 Filialen angebunden, die erst an einem Außenstandort gebündelt werden und dann über 100MBit hier in die Zentrale laufen. Aber auch noch ohne VoIP. Alle Filialen sind per ADSL angebunden. Mit drei Ausnahmen liegt alles zwischen DSL1000 und DSL6000. In der Zentrale hab ich als Backup noch einen 150MBit Kabelinternetanschluss. Für den Fall der Fälle reichts, ist dafür aber günstig. Zwei Glasfasern wären definitiv zu teuer.

[Jirka]

Hallo,

D.h. ich bräuchte auf dem LANCOM-Router der Außenstelle jeweils einen Content-Filter der dort zu verwalten ist, oder nicht?

Genau.

Oder gibt es eine Sync-Möglichkeit, d.h. wenn ich den Content-Filter auf nem 7100er auf der Zentrale verwenden würde und dann auf allen 1781er auf den Zweigstellen, dass ich das nur an einer Stelle pflege und es wird auf allen gesynced?

Nun ja, mit den üblichen Methoden: Scripting (dabei muss man das (Teil-)Script erst auslesen und anschließend in die anderen Router einspielen; mit ein wenig Routine wärst Du bei jeder Änderung mit 30 Sekunden dabei) und Gruppenkonfiguration (hier werden direkt alle Geräte gemeinsam konfiguriert; natürlich nur für den Content-Filter und z. B. nicht für die Firewall, denn die IP-Netze unterscheiden sich ja überall).

Viele Grüße,
Jirka

EDIT: Falsche Angabe von mir zur CPU beim 1781A-4G gelöscht.

[Koppelfeld]

Ich würde aber in den Niederlassungen den 1781*V*A-4G bevorzugen.
Zum einen bist Du flexibler, zum anderen ist die CPU wesentlich leistungsfähiger,

Also der 1781VA-4G in natürlich flexibler, aber der 1781A-4G hat die gleiche CPU. Nur der ältere 1781-4G hat die kleine drin.

Das wurde mir auch mitgeteilt. Aber sieh' selbst:
Hier ein 1781A-4G:
| CPU-Takt-MHz 398
| CPU-Typ Freescale MPC8314E 1.2 (core 2.0)
| Ethernet-Switch-Typ AR8327 Rev. 2.0
| Extended-Name LANCOM 1781A-4G
... hier ein 1781-4G:
| CPU-Takt-MHz 398
| CPU-Typ Freescale MPC8314E 1.2 (core 2.0)
| Ethernet-Switch-Typ AR8327 Rev. 1.1
| Extended-Name LANCOM 1781-4G
... und hier ein 1781VA:
| CPU-Takt-MHz 796
| CPU-Typ Freescale P1014E 1.0 (core 2.0)
| Ethernet-Switch-Typ AR8327N Rev. 2.0
| Extended-Name LANCOM 1781VA (over ISDN)

Mir fiel das erst auf, als ich der Frage nachging, weshalb die CPU-Belastung so hoch war.
Ärgerlich. Ich weiß aber nicht, wer bei LANCOM mir das erzählt hat.

[Jirka]

Hallo Koppelfeld,

Du hast Recht! Ich nehme alles zurück und behaupte das Gegenteil! In meinem Beitrag oben habe ich die Passage gelöscht.

Besser ist wirklich, man schaut ins Gerät, da war ich aber gestern um die Uhrzeit zu faul für... (obwohl es ja nur wenige Klicks gewesen wären, aber irgendwie war ich mir zu sicher...)

Board-Revision INFO: B
CPU-Clock-MHz INFO: 398
CPU-Type INFO: Freescale MPC8314E 1.2 (core 2.0)
Ethernet-Switch-Type INFO: AR8327 Rev. 2.0
Extended-Name INFO: LANCOM 1781A-4G
MOD-level INFO: B4
Model-Number INFO: LANCOM 1781A-4G
Onboard-USB-Hub INFO: Yes
PLD-Version INFO: -
Security-Engine INFO: Yes
Total-Memory-KBytes INFO: 131072

Also sorry und danke für Deinen Einspruch...

Viele Grüße,
Jirka

P.S.: Aber irgendwo musste ich die Info haben, ich glaube es war Deine Angabe hier im Forum (http://www.lancom-forum.de/lancom-syste ... tml#p75720), nach der ich damals sogar gesagt habe ein 1781A-4G reicht... Da ich das alles auch nicht in Frage gestellt habe, habe ich das auch nie überprüft. Ist ja echt ein Ding...

[Bernie137]

Hallo,

bzgl. Content Filter:
Ich weis ja nicht, wie weit es schon umgesetzt ist. Nach meiner Erfahrung taugt der Lancom ContentFilter und auch alle anderen Produkte, die anhand der Client-IP filtern nicht in einem solchen Szenario. Ganz einfach weil der Terminal-Server immer eine IP für ganz viele User hat. Es hat sich nicht bewährt dafür die ab Win Server 2008/R2 enthaltene Funktion pro User-Session eine eigene IP zuvergeben anzuwenden. Man kommt oft nicht umhin, es anhand von Active Directory Gruppen basiert zu filtern, d.h. Gruppe A hat diese Rechte, Gruppe B hat jene Rechte bzgl. Surfen unabhängig von welchem Device/IP-Adresse aus gesurft wird.

zum Surfen an sich:

Wir müssen aber auch folgendes unterscheiden, bevor wir aneinander vorbeischreiben:
- Lokales Surfen auf dem Client
- Surfen auf dem Server

...

Weitere Unterscheidung ist eben das Routing:
1. Lokales Surfen auf dem Client direkt über die Leitung
2. Lokales Surfen auf dem Client geroutet über den VPN-Tunnel

Richtig. Das ist exakt wie bei uns, nur wir haben es in kleinerem Rahmen. Bei uns wird "- Surfen auf dem Server" durchgeführt mit all seinen Nachteilen, denn es gibt bei uns ein KO-Kriterium. Durch den Einsatz von ThinClients die hauptsächlich linuxbasierend sind, ist es nicht (ohne Weiteres) möglich zwischen RDP-Sitzung und lokaler Oberfläche zu wechseln - man muss sich da schon komplett vom TerminalServer abmelden und das ist höchst userunfreundlich. Ganz einfach weil der RDP Client unter Linux keine RDP "Connection Bar" besitzt. Auch ist ein Surfen an lokalen FatClients vereinzelt zugelassen per Zugriff über den VPN-Tunnel, also eher Deiner Variante 2 entsprechend, mit dem Unterschied es ist kein Routing, sondern ein Proxyzugriff auf die Zentrale. Probleme sind hierbei ganz klar: Die User nutzen das schamlos aus und fangen an, sich Kram auf Sticks zu laden oder glotzen Müll auf Youtube (trotzdem braucht man es für Schulungsvideos) und das bremst den RDP-Traffic ungemein aus, daher wird http/https enorm per Firewall eingebremst. Vondaher musst Du Dir darüber keinen Kopf machen:

ABER, über den VPN-Tunnel erreicht man nicht die volle Geschwindigkeit der Leitung. Meine Messungen haben ergeben, z.B. bei einem 50Mbit VDSL:
- Internet direkt: ca. 40Mbit
- Internet über den VPN Tunnel geroutet: ca. 18Mbit
- bei IPSec über HTTPS kommen sogar nur noch 3Mbit raus

Früher oder später hast Du das selbe Problem und bremst lokalen Suftraffic ohnehin ein.

zu den TerminalServern:

Nein, das NoMachine ist wesentlich günstiger als eine reine RDP-Lösung, denke an die "CAL"s!
Bei NoMaschine bist Du mit einer Enterprise-Lizenz für etwa 1.500,-- dabei. Weil aber auch Server einmal ausfallen können, würde ich eine zweite Maschine danebenstellen - gerne auch laufend, mit einfacher Lastverteilung per round-robin. Macht also ZWEI an den "Terminalserver" angeschlossene Clients. Die beiden Clients lizensierst Du mit den "TS-CAL"s und den "Server-CAL"s. Das kostet Dich, bei zwei "Terminalservern" und zwei NX-Servern, etwa 700,--.
Für das ganze Setup mit Deinen 300 Usern kommen also 2.200 Euro zusammen.

Ich kenne die Fremprodukte nicht und weis nicht wie es korrekt lizenziert wird, aber: bei 300 bis 350 Usern macht man nicht nur 2 TerminalServer. Wir haben täglich an die 100 TerminalUser und die sind verteilt auf 4 TerminalServer. Das ist recht entspannt, wenn mal eine auch mal zwei Maschinen ausfallen oder man SoftwareUpdates oder Wartung machen möchte. Von daher hier nicht an der falschen Stelle sparen. Vielleicht sind wir da etwas überdimensioniert, aber bei 300 Usern zwei RDP-Server ist definitiv zu wenig, besonders wenn Geld da ist für

Zentrale mit 2 x 150Mbit Glasfaser/Festanbindung

vg Bernie

[vitaminc]

Nein, das NoMachine ist wesentlich günstiger als eine reine RDP-Lösung, denke an die "CAL"s!
Bei NoMaschine bist Du mit einer Enterprise-Lizenz für etwa 1.500,-- dabei. Weil aber auch Server einmal ausfallen können, würde ich eine zweite Maschine danebenstellen - gerne auch laufend, mit einfacher Lastverteilung per round-robin. Macht also ZWEI an den "Terminalserver" angeschlossene Clients. Die beiden Clients lizensierst Du mit den "TS-CAL"s und den "Server-CAL"s. Das kostet Dich, bei zwei "Terminalservern" und zwei NX-Servern, etwa 700,--.
Für das ganze Setup mit Deinen 300 Usern kommen also 2.200 Euro zusammen.
Die NX-Server, weil sie ja sowieso breitbandig am Internet hängen, sind eine erstklassige Wahl, um dann auch noch einen Telephonieserver redundant draufzupacken. Dann ist das Thema gleich mit abgefrühstückt.

Interessanter Ansatz. Zunächst sei aber gesagt das wir keine kleine Umgebung haben, d.h. wir sind fest mit Vmware und Hyper-V aufgestellt.
Unsere Terminalserver, aktuell 7 in der Zahl, sind virtuelle Maschinen und stehen über 550 Usern bereit. Ich weiß ich hatte 5-6 User im Schnitt pro Standort geschrieben, damit waren aber nur die Standard-Zweigstellen gemeint, d.h. ohne Zentrale und 2t-Zentrale.
Aber ich gucke mir die Lösung auf jeden Fall an und werde es mit RDP 2012 vergleichen, nächstes Jahr kommt evtl. Windows 2016 Server und das Projekt der Umstrukturierung ist auch für 2016 geplant.

Das tut überhaupt nicht weh. Wichtig ist, daß Interngespräche auch intern bleiben und nicht über die Zentrale geschleift werden. Ich würde aber in den Niederlassungen den 1781*V*A-4G bevorzugen.
Zum einen bist Du flexibler, zum anderen ist die CPU wesentlich leistungsfähiger, bei den vielen kleinen SIP- und RT(C)P-Paketchen nicht ganz unwichtig.

Den 1781-VA-4G habe ich bereits im Einsatz, gutes Gerät, wenn man da zusätzlich noch WLAN direkt anbinden könnte ohne noch nen separaten AP kaufen zu müssen dann wäre er noch besser

Wir sind vielfach mit DSL 6.000 geschlagen - und ja, da betreiben wir einen Holzfachmarkt mit 20 Mitarbeitern drüber.

Unsere Standorte sind aktuell auch weitestgehend mit MPLS 6 oder 16Mbit ADSL + UMTS Backup ausgestattet. Ansich keine schlechte Lösung, vorallendingen wenn der DSL 16Mbit gut läuft.. ich habe mit ADSL-Anschlüssen an die 99,8% Verfügbarkeit, quasi kaum Probleme/Abstürze.

3G funktioniert.
Ein LTE-Stick wäre schneller geklaut als ein Lämmchen mit dem Schwanz wackeln kann.
Eine externe Yagi-Antenne ist zudem preisgünstig und ungemein effektiv. Und ja, die Strippe darf ruhig 20 m lang sein. Klar sind das 10 dB Dämpfung, aber Du hast 9 dB Antennengewinn, aber ein wesentlich besseres S/N - Verhältnis.

Ja, 3G ist das was ich mit dem normalen 1781-VA nutze, ABER die USB-Stick Kombatiblität ist unter aller Kanone bei Lancom. Egal, ab sofort kaufe ich nur noch den 4G. Thema: Antennenverstärkung, ja das ist klar, da wo es nicht gut am Standpunkt funzt, muss halt individuell ne externe Antenne dran.

Immer über den VPN-Tunnel - dann hast Du die Möglichkeit, Thin Clients einzusetzen. Wenn die Spielkinder erstmal Internet lokal haben, dann gute Nacht. Da kann man ja gleich eine UZI in den Schimpansenkäfig schmeißen.
Wenn Du in den Niederlassungen auf PCs verzichtest, sparst Du dir zudem den "Virenschutz".
Wichtiger aber ist, daß, wenn der User seinen "PC" nicht mehr "optimieren" muß, mehr Zeit für die beruflichen Tätigkeiten bleibt.
Bei über 300 Usern muß man auch einmal den Stromverbrauch bedenken.

Wir haben keine PC's für die normalen Arbeitsplätze, quasi nur Thin Clients mit Windows Embedded, meistens sogar Dual oder Quad-Core Maschinen.
Lokales Surfen möchte ich beibehalten, aber es wird halt durch den Tunnel geroutet.

[vitaminc]

Bei MPLS musst du bedenken, dass du an deinen Anbieter mehr oder weniger gebunden bist. Im Gegenzug hast du QoS. Eine garantierte Bandbreite hast du nicht, weil dein Engpass die Zentrale ist. Für eine garantierte Bandbreite, bräuchstest du hier einen Anschluss, der eine Bandbreite in Höhe der Summe aller Filialanschlüsse hat. Eine Kommunikation zwischen den Filialen wird es sicher nicht geben.

Eine Kommunikation zwischen den Filialen wird tatsächlich nicht benötigt.
Engpass der Zentrale lässt sich beheben durch Erhöhung der Bandbreite, was dann auch weitere hohe Kosten verursacht.

Beim VPN-Overlay-Netz hast du die freie Auswahl des Anbieters. Wenn Provider A nichts anbieten kann oder das Angebot nicht tragbar wäre, nimmt man halt Anbieter B. Ich hab z.B. eine Filiale, bei der die Telekom selbst DSL768 nicht stabil anbieten kann. Aber beim Aufbau des Centers wurde in jede Mietfläche eine Glasfaser eingezogen.

Identische Erfahrung. Hab ne Filiale in nem Industriegebiet, HVT zu weit entfernt für jegliche DSL Produkte, also gibts nur teure Festverbindung. Zum Glück hat die dortige Stadtwerke Glasfaser liegen, haben es uns ins Haus gelegt und zahlen jetzt 50/7 ca. 70 EUR im Monat. Läuft Super!

Ich sehe das mit der Auswahl an Anbietern auch als großen Vorteil, wobei dann aber mehr Verwaltungsaufwand für unseren eigenen Support vorhanden ist. Eine homogene Landschaft ist halt immer schöner.. auch was Preisgestaltung angeht, wenn man bei einem Anbieter ist, wird man wie wir direkt gleich als Großkunde-A geführt. Da bekommt man bessere Preise und hat natürlich auch gute persönliche Ansprechpartner. Das zahlt man aber auch alles.

Du schreibst jetzt von Internetanbindungen der Zentrale. Zwei verschiedene Provider? Wenn ja, verlierst du durch das MPLS an Redundanz. Hier müssen ja beide Leitungen vom gleichen Provider kommen und die landen mit hoher Wahrscheinlichkeit am Ende im gleichen Verteilerknoten.

Nein, es ist 1 Provider mit 2 x 150Mbit von je unterschiedlichen Leitungsträgern. Es ist also nur 1 MPLS, die beiden großen CISCO sind balanced und rendundant.

Wie ist dein VoIP realisiert? Haben die Filialen eine Nummer aus dem Ortsnetz und du willst noch eine zusätzliche Vernetzung aufbauen oder werden alle Telefonanschlüsse über die Zentrale bereitgestellt?

Wir haben noch kein VoIP. Das gilt es aufzubauen. Ich liebäugel aktuell mit 3CX, das ganze auf VMWare (ESXi) auf der Zentrale laufen zu lassen. Die ganzen ISDN-Anschlüsse sollen in SIP-Trunks gewandelt werden die dann alle auf der Zentrale liegen. An den Standorten nur noch Telefone mit Provisioning etc.. so dass die Mitarbeiter keine Arbeit mehr mit dem Thema haben. Klassische Zentralisierung!!
Meint Ihr das ist keine gute Idee?

Die 150MBit werden wohl reichen. Ich habe 80 Filialen angebunden, die erst an einem Außenstandort gebündelt werden und dann über 100MBit hier in die Zentrale laufen. Aber auch noch ohne VoIP. Alle Filialen sind per ADSL angebunden. Mit drei Ausnahmen liegt alles zwischen DSL1000 und DSL6000. In der Zentrale hab ich als Backup noch einen 150MBit Kabelinternetanschluss. Für den Fall der Fälle reichts, ist dafür aber günstig. Zwei Glasfasern wären definitiv zu teuer.

Es sind 300Mbit (2x150)
ADSL nutzen wir derzeit auch noch, steige aber derzeit Schritt für Schritt aus dem MPLS aus, löse die ADSL Anschlüsse die nicht gut laufen auf und wechsel zu VDSL, SDSL, regionale Produkte, auch Kabelanbieter könnten interessant sein. Dennoch ist das letzte Wort noch nicht gesprochen, d.h. MPLS ist noch nicht vom Tisch.

[vitaminc]

Hallo,

bzgl. Content Filter:
Ich weis ja nicht, wie weit es schon umgesetzt ist. Nach meiner Erfahrung taugt der Lancom ContentFilter und auch alle anderen Produkte, die anhand der Client-IP filtern nicht in einem solchen Szenario. Ganz einfach weil der Terminal-Server immer eine IP für ganz viele User hat. Es hat sich nicht bewährt dafür die ab Win Server 2008/R2 enthaltene Funktion pro User-Session eine eigene IP zuvergeben anzuwenden. Man kommt oft nicht umhin, es anhand von Active Directory Gruppen basiert zu filtern, d.h. Gruppe A hat diese Rechte, Gruppe B hat jene Rechte bzgl. Surfen unabhängig von welchem Device/IP-Adresse aus gesurft wird.

Ich seh schon dass Lancom in Bezug auf Content-Filter zu wenig bietet. SPNEGO+SSO sind halt Mittel der Wahl wenn es um Terminalserver geht, nur so kann man bei uns Benutzerspezifisch das Regelwerk für Content aufbauen. Mit ein Grund warum wir den Content Filter der dicken Firewalls nutzen.

zum Surfen an sich:
Richtig. Das ist exakt wie bei uns, nur wir haben es in kleinerem Rahmen. Bei uns wird "- Surfen auf dem Server" durchgeführt mit all seinen Nachteilen, denn es gibt bei uns ein KO-Kriterium. Durch den Einsatz von ThinClients die hauptsächlich linuxbasierend sind, ist es nicht (ohne Weiteres) möglich zwischen RDP-Sitzung und lokaler Oberfläche zu wechseln - man muss sich da schon komplett vom TerminalServer abmelden und das ist höchst userunfreundlich. Ganz einfach weil der RDP Client unter Linux keine RDP "Connection Bar" besitzt. Auch ist ein Surfen an lokalen FatClients vereinzelt zugelassen per Zugriff über den VPN-Tunnel, also eher Deiner Variante 2 entsprechend, mit dem Unterschied es ist kein Routing, sondern ein Proxyzugriff auf die Zentrale. Probleme sind hierbei ganz klar: Die User nutzen das schamlos aus und fangen an, sich Kram auf Sticks zu laden oder glotzen Müll auf Youtube (trotzdem braucht man es für Schulungsvideos) und das bremst den RDP-Traffic ungemein aus, daher wird http/https enorm per Firewall eingebremst. Vondaher musst Du Dir darüber keinen Kopf machen:

Besser ist es den USB-Port auf Lese/Schreibzugriff zu sperren, so dass nur normale Devices betrieben werden können.
Es ist niemals einfach nen guten Kompromiss aus Sicherheit, Geschwindigkeit und Komfort zu finden.

Ich kenne die Fremprodukte nicht und weis nicht wie es korrekt lizenziert wird, aber: bei 300 bis 350 Usern macht man nicht nur 2 TerminalServer. Wir haben täglich an die 100 TerminalUser und die sind verteilt auf 4 TerminalServer. Das ist recht entspannt, wenn mal eine auch mal zwei Maschinen ausfallen oder man SoftwareUpdates oder Wartung machen möchte. Von daher hier nicht an der falschen Stelle sparen.

Kommt stark auf die Ressourcen und Anwendungen der Maschinen an. Wie gesagt wir haben 7 VM's als Terminalserver, da hat jeder VM ca. 60-70 User drauf.
Man kann auch weniger Server mit mehr Leistung fahren, aber bei kritischen Anwendungen bei denen 1 User direkt mal 50% CPU-Dauerlast erzeugen kann halte ich das für riskant. Ja, es gibt so Tools wie Threadmaster und Co, aber auch da ist Vorsicht geboten wie ich finde.

Übrigens sehr nette Runde hier..

[5624]

Ich bin gerade auch am Thema VoIP dran und ich werde es definitiv nicht zentralisieren. Ich bau es lieber so, dass ich die Telefonie nach Standard baue und auch alles durch die Filiale tauschbar. Einziger Unterschied zur Anlage aus dem Einzelhandel ist ein Kabelsatz aus drei Kabeln, der Anschlusskabel steckbar macht.

Sprich bei mir ist es entweder ein Problem der Telekom, wenn die komplette Telefonie ausfällt oder es betrifft nur eine Filiale. Für den Fall, es VPN-Probleme gibt, läuft die Telefonie weiter, weil es direkt lokal ausgekoppelt wird.

Wir haben aber auch Türsprechstellen, die grundsätzlich laufen sollte (Anlieferung durch Paketdienste), was bei lokalen Anlagen selbst durch einen Anbindungsausfall nicht gestört werden kann.

Selbst die Konfig der Telefonanlagen ist so identisch, dass nur noch zwei Rufnummern getauscht werden müssen.

Zur Providerwahlfreiheit: Am Ende bin ich mit allen Anschlüssen doch bei der Telekom gelandet. Während Neueröffnungen greift man dann mal kurz zu Behelfsanschlüssen von Fremdprovidern, aber Ziel ist immer die Telekom. LTE-Backup läuft noch über Voodoofone.

[vitaminc]

Ich bin gerade auch am Thema VoIP dran und ich werde es definitiv nicht zentralisieren. Ich bau es lieber so, dass ich die Telefonie nach Standard baue und auch alles durch die Filiale tauschbar. Einziger Unterschied zur Anlage aus dem Einzelhandel ist ein Kabelsatz aus drei Kabeln, der Anschlusskabel steckbar macht.

Sprich bei mir ist es entweder ein Problem der Telekom, wenn die komplette Telefonie ausfällt oder es betrifft nur eine Filiale. Für den Fall, es VPN-Probleme gibt, läuft die Telefonie weiter, weil es direkt lokal ausgekoppelt wird.

Wir haben aber auch Türsprechstellen, die grundsätzlich laufen sollte (Anlieferung durch Paketdienste), was bei lokalen Anlagen selbst durch einen Anbindungsausfall nicht gestört werden kann.

Selbst die Konfig der Telefonanlagen ist so identisch, dass nur noch zwei Rufnummern getauscht werden müssen.

Zur Providerwahlfreiheit: Am Ende bin ich mit allen Anschlüssen doch bei der Telekom gelandet. Während Neueröffnungen greift man dann mal kurz zu Behelfsanschlüssen von Fremdprovidern, aber Ziel ist immer die Telekom. LTE-Backup läuft noch über Voodoofone.

Ist auch eine Möglichkeit, ich ziele dennoch auf eine zentrale Lösung ab aufgrund unseres echten Rechenzentrum-Betrieb (24/7) mit den 2 Classic Premium Anschlüssen.
Evtl. dann ein Disaster Recovery RZ auf der 2ten Zentrale (400km entfernt vom 1sten RZ) aufbauen, so dass die VMware im Bedarfsfall dort starten kann und der Betrieb weitergeführt werden kann.
Ist halt immer eine Frage wie schmerzhaft ein Ausfall für das Unternehmen ist.

Darf man fragen welche Lösung/Hersteller Du verwenden möchtest?
Du wirst SIP-Trunk einsetzen oder Gateways mit ISDN?
Und wie willst Du FAX lösen?

Ich hoffe ja weiterhin auf den schnellen Tod von Fax

[Koppelfeld]

Zunächst sei aber gesagt das wir keine kleine Umgebung haben, d.h. wir sind fest mit Vmware und Hyper-V aufgestellt.
Unsere Terminalserver, aktuell 7 in der Zahl, sind virtuelle Maschinen und stehen über 550 Usern bereit. Ich weiß ich hatte 5-6 User im Schnitt pro Standort geschrieben, damit waren aber nur die Standard-Zweigstellen gemeint, d.h. ohne Zentrale und 2t-Zentrale.

Wir habe einmal 440 User auf mehreren wirrtualisierten Servern gehabt, mit nur ganz wenigen Kernanwendungen. Die "VMWare" zeigte wenig CPU-Last und wenig I/O und dennoch maulten alle User über grottenschlechte Antwortszeiten.
Dann habe ich die 440 User einfach 'mal auf ein (allerdings ziemlich leistungsstarkes) HX5-Blade geschoben, und zwar 'bare metal', und die User waren glücklich.
Eigentlich keine Überraschung:

- Der Hypervisor mit seinen 'meta context switches' macht natürlich die 'refernzielle Lokalität' ziemlich kaputt und sorgt dafür, daß die Caches regelmäßig nachgeladen werden müssen. TLB misses sind richtig teuer - aber man sieht sie nicht in der "Auslastungsstatistik".

- Ganz übel sieht es mit dem Netzwerk aus: Die VMWare "simuliert" einen Switch mit einem 08/15 - Universalprozessor, ein richtiger Switch schafft Parallelität mit FPGAs. Aber eigentlich ist es noch schlimmer: Du hast beim Ansprechen einer physikalischen Netzwerkkarte reichlich Kernel/Userspaceübergänge, denn Du gehst ja von der gehosteten Partition erst in den Hypervisor, vo da aus in die verwaltende Partition und den dort simulierten Switch, von da aus wieder in den Hypervisor und dann erst auf den Prozessor der physischen Netzwerkkarte. Und die kann ihre speziellen Fähigkeiten, von scatter-gather vielleicht abgesehen, gar nicht so ausspielen (TCP-Offloading z.B.). Performance darfst Du da nicht erwarten, speziell, wenn Du noch einen VoIP-Server mit seinen vielen kleinen Paketchen da drin betreibst.
Deswegen haben, mit Verlaub gesagt, erwachsene Virtualisierungsumgebungen ja auch Spezialhardware wie zum Beispiel IBMs "IVE" ("Integrated Virtual Ethernet"), welche eigentlich eine Karte mit 12 Netzwerkinterfaces und einem integrierten 10 GB/s - Switch darstellt. Der Hypervisor gibt der gehosteten Partition nun einen Handle und in der Folge verfügt der virtuelle Rechner über echte Hardware mit echter eigener MAC. Damit kriegt man die Leistung dann auch zum User. Prozessorleistung wird auf spezialisierte Hardware ausgelagert, cache trashing wird vermieden.
Das Dumme ist nur: Das gibt es nicht für "Windows".

- Richtig eklig wird es beim I/O:
Eine "Festplatte" wird simuliert mit einer ranzigen Linux-Datei. Ja, wenn es denn ZFS wäre, ist es aber nicht. Im oben genannten Beispiel hatte jeder "Terminalserver" 420.000 (!) File Handles offen, davon waren garantiert ein Viertel "plattenbezogen". Eine Linux-Datei freilich wurde nie dafür konzipiert, 100.000-fach im Zugiff zu sein. Bei jedem Dateizugriff gibt es notwendigerweise einen 'spin lock' und schon ist die Warterei geboren, denn wenn I/O auf I/O wartet, ist unvermeidlicher Stillstand die Folge.
Wenn Virtualisierung in Deiner Größenordnung, dann brauchst Du eine mit Block-I/O.

Zusammenfassend: Wirrtualisierung ist prima bei dem ganzen Zoo von Altanwendungen und Raritäten, die an ein ganz bestimmtes Verwesungsstadium von "Windows" gebunden sind. Sozusagen eine kompakte Sondermülldeponie.
Wenn Du allerdings für 500 User gute Antwortszeiten haben möchtest, dann würde ich es allen Ernstes mit einer 'bare metal' - Installation versuchen.
Ich mache Dir gerne 'mal einen Probezugang auf eine heftig belasteten MS-"Terminalserver".

[Koppelfeld]

Ist auch eine Möglichkeit, ich ziele dennoch auf eine zentrale Lösung ab aufgrund unseres echten Rechenzentrum-Betrieb (24/7) mit den 2 Classic Premium Anschlüssen.
Evtl. dann ein Disaster Recovery RZ auf der 2ten Zentrale (400km entfernt vom 1sten RZ) aufbauen

Das kannst Du einfacher haben: Zwei zentrale TK-Anlagen in jeder der beiden Zentralen permanent aktiv - und alle Telephone registrieren sich sowohl auf der einen als auch auf der anderen Anlage.
Annehmen tun sie von beiden Accounts. Zum 'raustelephonieren kriegt das Telephon eine Präferenz mit, wenn diese nicht verfügbar ist, nimmt es den Failover-Account. So haben wir das bei einer großen Tageszeitung gemacht, und das funktioniert ganz prima. Einzige Einschränkung: Die beliebten "Besetztlampenfelder" und deren Signalisierung sind bei manchen Telephonen an den primären Server gebunden - damit kann man aber gut leben.

so dass die VMware im Bedarfsfall dort starten kann und der Betrieb weitergeführt werden kann.

Nimm' für sowas einen Einzelserver.

Du wirst SIP-Trunk einsetzen oder Gateways mit ISDN?

Dein Vorposter schreibt, er wolle bei der Telekom bleiben. Die haben schlicht keinen "SIP-Trunk" im Angebot.

Doch gerade, wenn Du LANCOM einsetzt, bist Du doch allerbestens aufgehoben dank der göttlichen All-IP-Option ! Regelmäßige, kompetente User wie 'cpuprofi' bestätigen auch meine Erfahrung, daß die Telekom ihr Kerngeschäft nicht ansatzweise im Griff hat.
Deswegen nutzen wir für unsere Filialinstallationen die "All-IP-Option" genau umgekehrt, als 'squeeze-out - Option' für die Telekom:
Die Lancoms, typischerweise 1781VA, sind gegen 7100 oder 9100 vernetzt, ohne Probleme. Da bin ich echt dankbar, denn das war nicht immer so. Gleichzeitig ist natürlich auch ein evtl. bestehender ISDN-Anschluß dort eingesteckt. Mit der göttlichen Backup-Option brauchen wir uns über Kassenausfälle keine Gedanken zu machen, wir haben die Kassen als AS/400-Programm "virtualisiert" und mit 64 KBit/s betreibe ich leicht 20 Kassen. Die sind nebenher auch noch sehr preiswert, weil Thin Clients.
Wenn jetzt dort ein Telephonruf eingeht, dann wird dieser über den durch die 'squeeze-out' - Option realisierten ISDN / VoIP - Router stracks zur Zentrale geschickt und von da wieder über die zentralisierte TK-Anlage retour. Hebt in der Niederlassung jemand ab, gibt es natürlich seitens der TK-Anlage eine Aufforderung zum REINVITE, sodaß der Payload nicht unnützerweise hin- und hergeschickt werden muß. Aber die TK-Anlage bleibt im Signalisierungspfad und so kann man Besetztlampenfelder, Zentralefunktionen etc. realisieren.
Wenn dann die Telekom-Knebelverträge auslaufen, zieht man einfach den ISDN-Stecker und portiert die Niederlassungsnummer zu einem seriösen Provider - wenn es wenig Streß sein soll und gute Sprachqualität, dann ist QSC bei uns ein gesetzter Partner.
So kannst Du mit geringem Aufwand einen "weichen" Übergang bereitstellen, der sogar "lokale Notlauffunktionen" bietet.

Und wie willst Du FAX lösen?
Ich hoffe ja weiterhin auf den schnellen Tod von Fax

Das kannst Du haken. Intelligente Lösungen wie TELEX sterben schnell, gequirlte Scheiße überlebt ewig, ich sage nur "Heino" und "Fax". Ich weiß echt nicht, welches scheußlicher und entbehrlicher wäre. Dennoch kommen ausgerechnet richtig wichtige Dinge per Fax 'rein. Manche bringen es fertig, uns zehn Seiten *gleichzeitig* zu schicken.
Mit einer vernünftigen QoS (User Backslash hat hier erst vor kurzem detailliert beschrieben, wie das zu machen ist unter spezieller Betrachtung der Differenzierung von RTP und RTCP) hast Du da überhaupt keine Probleme. Normales G711A, Dejitterbuffer im Analogadapter nicht zu groß und vor allen Dingen nicht variabel auslegen, T.38 deaktivieren, evtl. die Parameter des Echo Cancellers anpassen.
Die Konfiguration der Analogadapter sollte natürlich, standortabhängig, zentral erfolgen können.

Auch da bist Du wieder mit LANCOM im Vorteil, denn die liefern Dir bei manchen Modellen "frei Haus" zwei Analogschnittstellen mit - die Du natürlich auch von der Ferne aus bedienen kannst.

Wenn Du solche Spezialitäten wie Failover, standort- und geräteabhängige Konfiguration, Re-Routing des RT(C)P-Datenstroms und solche Dinge machen willst, dann bist Du mit den "Studentenbudenlösungen" wie "Gemeinheit", "Moby Dick" (doch, das gibt es), "Stargaze", "Askotzia" und wie sie alle heißen ziemlich eingeschränkt. Mag sein, daß ein "Webinterface" sehr schön ist für die Degeneration der jungen Milden, die nix mehr verstehen und beherrschen wollen, aber ab 500 Nebenstellen ist da meistens Schluß mit Lustig. Man kann das vergleichen mit Hilfsrädern auf einem Fahrrad: Mag sein, daß man damit schnell erste Fahrergebnisse erzielt, aber wenn Du die ersten Erfahrungen gesammelt hast und Dich instinktiv schnittig in eine Kurve legst, fliegst Du auf die Fresse.
Bei TK-Anlagen fliegen dann auch gleich 500 Leute mit - und das ist der Grund, weshalb ich generell davon abraten würde, unternehmenskritische Infrastruktur unter Windows zu betreiben - erst recht nicht, wenn diese schön breitbandig im Internet steht.

Deswegen stets meine Empfehlung: Einfach ein Standard-Debian (Linux) mit einer Standard-Asterisk-Installation ausstatten, einfache Konfigsoftware installieren und einfach laufenlassen.

Anfangen (in den Zentralen) kann man sicherlich mit ISDN-Gateways, aber die sind richtig teuer, wenn es funktionieren soll. Wegen des sicherlich erforderlichen "weichen" Übergangs von Alt- auf Neutelephonie brauchst Du mindestens ein Gateway mit zwei PMX - Anschlüssen, damit Du im ersten Schritt zur Altanlage "durchschleifen" kannst. Das braucht dann 60 DSP-Kanäle und kostet entsprechend. Und es gibt so Dinge, Stichwort 'partial rerouting', da gibt es ganz gut Ärger.

Ich würde das anders erledigen und gleich zu einem seriösen Provider portieren - mit einem Monat Überlappung. Dabei ist es wichtig, daß das von einer Firma angeleiert wird, die den Providern bei Bedarf in die Eier treten kann. Projekte in Deiner Größenordnung würde ich nur mit einem spezialisierten Dienstleister machen.

Es gibt noch jede Menge anderer Gründe, die für eine telekomfreie, zentralisierte TK mit LANCOM sprechen, ein wichtiger Punkt ist, daß man nur einen einzigen DECT-Server in deiner der Zentralen braucht, um alle Niederlassungen zu bedienen (vor Ort muß natürlich eine Basisstation sein oder mehrere davon). Man kann dann, wegen der überall identischen ARI, mit seinem DECT-Telephon in jede beliebige Niederlassung fahren und das Telephon bucht sich automatisch ein.

Das alles ohne weitere Technik vor Ort, von Switchen und PoE-Adaptern einmal abgesehen. Nicht 'mal DHCP machen wir lokal, dank der DHCPRELAY-Funktion der Lancoms. Ein weiteres, komplizerteres Thema sind "Sonderfälle" wie EMA / BMA oder EC-Terminals, aber das würde den Umfang im Forum sprengen.

[Koppelfeld]

Aber irgendwo musste ich die Info haben, ich glaube es war Deine Angabe hier im Forum (http://www.lancom-forum.de/lancom-syste ... tml#p75720), nach der ich damals sogar gesagt habe ein 1781A-4G reicht... Da ich das alles auch nicht in Frage gestellt habe, habe ich das auch nie überprüft. Ist ja echt ein Ding...

Verdammte Tat. Das ist ja wie der Schiller'sche Fluch, der fortwährend Böses muß gebären.
Danke für den Hinweis, habe den Artikel gerade korrigiert.