magheinz

Ich würde zumindest versuchen ihn von der zentralen userverwaltung zu überzeugen...

Alternativ: Linux+samba

unter /etc/openvpn sollte eine config-date liegen. poste die mal, dann könne wir weiter sehen.

Das "aber trotzdem attacken zuverlässig erkennen" hätte mich interessiert.

Die Lösung würde mich auch interessieren...

Das ist b***d. Webgui ist immer so undurchsichtig. An sich ist die Aufgabe ja eher einfach. in cisco-Sprache: uplinkports: interface xyz switchport mode trunk switchport trunk allow vlan 1,2 accessports vlan 1: interface xyz switchport mode trunk switchport trunk native vlan 1 accessports vlan 2: interface xyz switchport mode trunk switchport trunk native vlan 2 mehr ist es doch nicht. Das ganze routing muss ja auf der firewall stattfinden, anders macht es ja keinen Sinn. VLAN 1 ist übrigens ungünstig, da es eh immer das default VLAN ist. Ich würde immer VLANs größer ein nehmen!

dann klär doch mal ab ob ein Server mit ordentlichen SLAs 7*24*4 und ein paar Ersatzteilen im Regal oder so + ordentliches Backup + ein Admin vor Ort nicht günstiger kommen alles eine echte HA-Umgebung.

und immer noch die Frage: wo soll das routing stattfinden? gibt bei HP sowas wie "show config" auf der console. Deine screenshots zeigen ja nur einen viertel der Wahrheit.

netapp FAS HA-Cluster. Je nach Anforderung ein oder zwei Gehäuse. Im Zweifelsfall dann ein Metrocluster. Sind denn zwei Brandabschnitte, zwei Stromeinspeisungen, Notstromdiesel o.ä. und ein redundant ausgelegtes Netzwerk vorhanden? HA und kein Admin vor Ort ist eh eine schlechte Ausgangslage! Budget zwischen Mitte 5stellig und hoch 6Stellig musst du dann aber einplanen! Da wäre es sinnvoller einen Admin einzustellen. Ob du trotzdem ein DFS dazwischenschalten willst musst du selber wissen. Das mit Windows- oder Linuxmittel nachzubauen wäre mir zu viel Bastelei. Einzige Variante: Storageserver virtualisieren und VMware HA+FT nutzen. Da könnte man dann z.B. FreeNAS nutzen.b

Du musst dir überlegen wo eigentlich geroutet werden soll. Auf der Firewall oder auf einem der Switche. Du scheinst auf jedem einzelnen Switch routen zu wollen was mir persönlich zu komplex wäre wenn es nicht einen verdammt triftigen Grund dafür gibt.

Wieso sind die uplinks "tagged"? Zwei ids kann man nicht gleichzeitig taggen. Die uplinks müssen trunks sein, die accessports taggen. Welcher der Switche routet denn oder gibts einen "externen" router? Wieso gibts auf zwei switchen jeweils ein layer3-interface für jedes vlan? Was ist als default gateway aus Switch X eingetragen?

Am Ende muss es die Geschäftsführung verantworten. Also muss abgeklärt werden was an Datenverlust akzeptabel ist. Das ist eine kaufmännische Entscheidung ausser es gibt externe Anforderungen wie z.b. Gesetze. Im Endeffekt muss geklärt werden: 1. Was kostet der Datenverlust 2. Kann man das durch Backups, die billiger sind als der Datenverlust verhindern. Es kann durchaus wirtschaftlicher sein Arbeit ein zweites mal zu machen als Backups zu haben.

Ob der Plan an sich ok ist kann nur die Geschäftsführung entscheiden ausser sie hat klare Vorgaben gemacht. Hat sie das, kann man die Frage nicht beantworten ob der Plan ok ist ohne die Vorgaben zu kennen. "immer am Montag" bedeutet ihr könnt auf eine Woche Daten verzichten?

Wenn "automatisch konfigurieren" ausgewählt ist, dann ist es doch logisch das genau das auch erfolgt. Ist die IP denn die vom DNS-Server?

Und je nach dem was du da an hardware hast kann man da sogar netapps draus machen.

Muss auf den Storagenodes unbedingt Windows laufen?

Geht wirklich nicht. Aber... In den meisten Fällen stellt man ja doch relativ schnell um. Man muss ja eh komplette cluster ins neue vcenter umziehen. Wie lange plant ihr denn den parallelbetrieb? Eventuell kann man auf einer Seite eine Zeit lang auf die Updates verzichten.

Ich würde das so im deploymemt machen. Temporären DNS-Eintrag setzen, Domain-beitritt, restliche Installationen, DNS korrigieren. So ähnlich machen wir das auch. Schau dir mal Foreman als Serverdeployment an. In Verbindung mit z.b. Puppet lässt sich da so gut wie alles automatisieren...

fehlen die <> nur im posting beim Empfänger? edit: beim Absender auch!

Das Standardverfahren bei uns besteht aus zwei haproxys im ha-cluster. Ist es möglich den Zieldienst auch unverschlüsselt zu erreichen terminieren wir ssl am haproxy, ist das nicht möglich leiten wir nur durch. Durch die Platzierung der LBs in der DMZ ist eine halbwegs saubere steuerung des Traffics zwischen DMZ und internen Netz möglich. Man muss aber unter Umständen aufpassen: Ssl braucht Zufall. Der Loadbalancer hat nur eine begrenzte Menge an Zufall schnell zur Verfügung. Bei wirklich hochfrequentierten Diensten kann es hier eng werden.

Das kann so nicht funktionieren und eigentlich auch nie funktioniert haben. Wer soll denn von intern die Ports irgendwohin weiterleiten? Hier findet doch gar kein routing, NAT etc statt. Der Traffic geht doch direkt vom client zum Server. Definiere einen hostname für den service im DNS und arbeite mit dem.

Nunja: Autorkorrektur von windowsphone halt. Break-fix war latürnich gemeint.

Das sehe ich auch so: Ein Supportvertrag mit einem Hardwarehersteller mit einen brake-fix in weniger als einem Tag ist ja jetzt auch nicht gerade billig. Wer sich das leisten kann der macht sich um ein paar GB RAM mehr oder weniger eh keine Gedanken. Standard sind 24*7*4. Das bedeutet nach 4 Stunden reagieren die aufs Ticket. bis der Fehler identifizert ist und der Techniker mit Ersatzteil da ist kann das durchaus mal 2 tage dauern. Ich habe von IBM schon Ersatzteile aus Holland kommen lassen. Da sind dann mit 2stunden Pickup+8Stunden Fahrt+2Stunden Einbau schon mal ein halber Tag weg. Und dann läuft nur die Hardware wieder. Jetzt kannst du erst den Restore anstossen. Du hast aber gerade deinen 8Stunden Arbeitstag erledigt. Wer steht denn dann überhaupt zur Verfügung um die Ersatzteile und den Techniker Nachts um 3 in Empfang zu nehmen? Ach ja: die 4 Stunden Reaktionszeit sind angestrebt, nicht garantiert und eher der Durchschnitt. Ich habe auch schon Freitags ein Ticket aufgemacht um dann Montags zu erfahren das sich am WE keiner drumm gekümmert hat Realistisch ist ein Tag Ausfall nur mit einem Cluster lösbar ausser man hat viel Geld, ein 3-Schicht-System in der IT etc.

Das ist er angeblich bei der letzten "nächsten Version" auch schon. Bei der letzten Präsentation der webclients(alter+neuer html5) auf der VMUG wurde doch sehr deutlich das die User den C#-Client bevorzugen. Bis vor kurzem konnte der webclient ja noch gar nicht alles. Selbst die Integration VMware-eigener Produkte war ja noch lange nicht vollständig. Ich erinnere nur an den Update-Manager. Von Drittherstellern will ich gar nicht erst reden.

Das erlebe ich auch immer wieder so. Einige Hersteller von Software haben keine Ahnung von den Datenbanken. Die DBs werden einfach nur als Datenspeicher genutzt. Um sinnvolle DB-Design macht sich da keiner Gedanken. Im Zweifelsfall wird halt etwas mehr Hardware empfohlen. Eine wirklich sinnvolle Empfehlung für die Serverausstattung kann es da gar nicht geben. Bei der letzten fragte ich nach den zu erwartenden IOs. Die Antwort war ein langes schweigen, und dann irgendwann: "na halt alles Standard".