10
Server Naming Convention
Hallöchen,
nach einiger Zeit gibt es tatsächlich mal ein Anliegen was ich mit den experten unter euch diskutieren möchte. Es ist für mich ein leidiges Thema und bis heute bin ich mit allen Lösungen äußerst unzufrieden.
Es geht um das Thema "Server Naming Conventions".
Meine Infrastruktur ist bestimmt etwas speziell, aber auch nicht außergewöhnlich, sodass ich denke, dass wir gemeinsam vielleicht eine tolle Struktur für mich finden.
Ich habe derzeit folgende Standorte:
Frankfurt (FRA1 und FRA2)
Hamburg (HAM)
Börnsen, Büro: SHB
Düsseldorf: DUS
Alle Standorte sind per VPN mit einander verbunden. FRA1 und FRA2 handeln gerade ein Interconnect für mich aus.
- FRA1 ist mein Hauptstandort wo ich ein eigenes Rack mit vollständig eigener Hardware betreibe.
- FRA2, HAM und DUS sind teilweise gemietet Hardware Server und teilweise eine virtuelle Umgebung.
Als Grundlage ist überall Proxmox am laufen um mit lxc und qemu zu virtualisieren.
Auf den virtuellen Maschinen laufen Kunden Projekte, Galera Cluster, Apache Nodes, Anwendungen wie Inventory, Atlassian Produkte, Mail Server, Spam Filter, DNS Server, Repository Server und und und.
Also wirklich alles läuft intern.
Was vielleicht noch wichtig ist: es läuft nur mit lokalen IPs, es gibt kein direktes Internet für die Systeme und wenn ein Dienst öffentlichen erreichbar sein muss, dann per NAT über die Firewall. Pakete und Downloads gehen nur über einen internen Repo Server (u.A. Pulp).
So, viel blah blah für bisschen Background Wissen. Danke an alle die noch nicht abgebrochen haben. :D
Jetzt möchte ich zwei Dinge tun: verschiedene Scopes definieren UND das Naming anpassen.
Scopes: Ich möchte alles in 4 Bereiche trennen und verschiene Scopes aufbauen: prod, test, core und infra.
Ob ich core (also interne Anwendungen) und infra nich zusammenlege bin ich derzeit am überlegen.
Angenommen meine Firma heisst "Brise".
Dann hätte ich aktuell die Domain: brise.intern
Zukünftig möchte ich für die 4 Bereiche 4 VLANs haben (ist derzeit in Arbeit) und je Scope eine Domain:
brise-prod.intern
brise-test.intern
brise-core.intern: graylog, jira, jenkins, repos.
brise-infra.intern: das sind sachen wie Switche, Firewall, Hardware Nodes, KVMoIP, IPMI...
Die Kommunikation zwischen prod und test wird dabei vollständig verboten um auch mal bei Deployment Fehlern keine Probleme zwischen die Daten der Scopes zu verursachen. Auch aus Sicherheitsgründen.
brise.intern soll nur als Alias Domain dienen um Namen wie "jira.brise.intern" möglich zu machen. Keiner mag sich lange Namen merken :D
Wenn keiner was wegen den Scopes sagt, dann lasse ich es so. Damit bin ich generell zufrieden.
Naming:
Sehr schwierig. Eigentlich will ich viele Informationen im Namen haben, andererseits auch nicht zu lange (glaube 16 Zeichen sollen maximal sein).
Hatte sowas wie:
fra1-dbc1-m1.brise-prod.intern
fra2-dbc1-m2
fra1-dbc1-m3
überlegt. Man sieht den Standort, den Context (hier das Cluster: dbc1= Database Cluster 1) und die Sequenz Nummer (m1 = member 1).
Für Kunden kann man noch ein Tag ergänzen.
Das ist tatsächlich mein Favorit. Jetzt stellt sich nur eine entscheidende Frage:
Wie baue ich das Testcluster auf?
fra1-dbc1-m1.brise-test.intern?
oder
fra1-dbc2-m1.brise-test.intern
Theoretisch das erste Cluster in dem Scope. Andererseits das zweite Cluster auf die ganze Infrastruktur bezogen.
Es gibt auch die Möglichkeit wie:
dbc1-m1.fra1.brise-prod.intern
dbc1-m2.fra2.bride-prod.intern
Generell aber gleiches Problem wie oben. Aber Standort per Subdomain geregelt. Find ich glaube aber nicht sooo lecker.
Andere machen auch sowas wie:
fra1dbc1m1.brise-prod.intern
Find ich aber zu unleserlich, das ja wie ein Random Name :D
Wichtig ist: es gibt viele Cluster über mehrere Standorte. Grade Standorte wie FRA1 und FRA2 wo ich dediziert mit 10G Daten schieben kann habe ich das gerne.
Deshalb ist der Standort im Naming fast unabdingbar.
Was für Ideen habt ihr, was nutzt ihr? Was für Anmerkungen habt ihr?
Generell kann ich natürlich irgendwas nehmen: aber möchte etwas nachhaltiges, logisches und sinnvolles.
Freue mich auf euer Feedback!
Grüße
nach einiger Zeit gibt es tatsächlich mal ein Anliegen was ich mit den experten unter euch diskutieren möchte. Es ist für mich ein leidiges Thema und bis heute bin ich mit allen Lösungen äußerst unzufrieden.
Es geht um das Thema "Server Naming Conventions".
Meine Infrastruktur ist bestimmt etwas speziell, aber auch nicht außergewöhnlich, sodass ich denke, dass wir gemeinsam vielleicht eine tolle Struktur für mich finden.
Ich habe derzeit folgende Standorte:
Frankfurt (FRA1 und FRA2)
Hamburg (HAM)
Börnsen, Büro: SHB
Düsseldorf: DUS
Alle Standorte sind per VPN mit einander verbunden. FRA1 und FRA2 handeln gerade ein Interconnect für mich aus.
- FRA1 ist mein Hauptstandort wo ich ein eigenes Rack mit vollständig eigener Hardware betreibe.
- FRA2, HAM und DUS sind teilweise gemietet Hardware Server und teilweise eine virtuelle Umgebung.
Als Grundlage ist überall Proxmox am laufen um mit lxc und qemu zu virtualisieren.
Auf den virtuellen Maschinen laufen Kunden Projekte, Galera Cluster, Apache Nodes, Anwendungen wie Inventory, Atlassian Produkte, Mail Server, Spam Filter, DNS Server, Repository Server und und und.
Also wirklich alles läuft intern.
Was vielleicht noch wichtig ist: es läuft nur mit lokalen IPs, es gibt kein direktes Internet für die Systeme und wenn ein Dienst öffentlichen erreichbar sein muss, dann per NAT über die Firewall. Pakete und Downloads gehen nur über einen internen Repo Server (u.A. Pulp).
So, viel blah blah für bisschen Background Wissen. Danke an alle die noch nicht abgebrochen haben. :D
Jetzt möchte ich zwei Dinge tun: verschiedene Scopes definieren UND das Naming anpassen.
Scopes: Ich möchte alles in 4 Bereiche trennen und verschiene Scopes aufbauen: prod, test, core und infra.
Ob ich core (also interne Anwendungen) und infra nich zusammenlege bin ich derzeit am überlegen.
Angenommen meine Firma heisst "Brise".
Dann hätte ich aktuell die Domain: brise.intern
Zukünftig möchte ich für die 4 Bereiche 4 VLANs haben (ist derzeit in Arbeit) und je Scope eine Domain:
brise-prod.intern
brise-test.intern
brise-core.intern: graylog, jira, jenkins, repos.
brise-infra.intern: das sind sachen wie Switche, Firewall, Hardware Nodes, KVMoIP, IPMI...
Die Kommunikation zwischen prod und test wird dabei vollständig verboten um auch mal bei Deployment Fehlern keine Probleme zwischen die Daten der Scopes zu verursachen. Auch aus Sicherheitsgründen.
brise.intern soll nur als Alias Domain dienen um Namen wie "jira.brise.intern" möglich zu machen. Keiner mag sich lange Namen merken :D
Wenn keiner was wegen den Scopes sagt, dann lasse ich es so. Damit bin ich generell zufrieden.
Naming:
Sehr schwierig. Eigentlich will ich viele Informationen im Namen haben, andererseits auch nicht zu lange (glaube 16 Zeichen sollen maximal sein).
Hatte sowas wie:
fra1-dbc1-m1.brise-prod.intern
fra2-dbc1-m2
fra1-dbc1-m3
überlegt. Man sieht den Standort, den Context (hier das Cluster: dbc1= Database Cluster 1) und die Sequenz Nummer (m1 = member 1).
Für Kunden kann man noch ein Tag ergänzen.
Das ist tatsächlich mein Favorit. Jetzt stellt sich nur eine entscheidende Frage:
Wie baue ich das Testcluster auf?
fra1-dbc1-m1.brise-test.intern?
oder
fra1-dbc2-m1.brise-test.intern
Theoretisch das erste Cluster in dem Scope. Andererseits das zweite Cluster auf die ganze Infrastruktur bezogen.
Es gibt auch die Möglichkeit wie:
dbc1-m1.fra1.brise-prod.intern
dbc1-m2.fra2.bride-prod.intern
Generell aber gleiches Problem wie oben. Aber Standort per Subdomain geregelt. Find ich glaube aber nicht sooo lecker.
Andere machen auch sowas wie:
fra1dbc1m1.brise-prod.intern
Find ich aber zu unleserlich, das ja wie ein Random Name :D
Wichtig ist: es gibt viele Cluster über mehrere Standorte. Grade Standorte wie FRA1 und FRA2 wo ich dediziert mit 10G Daten schieben kann habe ich das gerne.
Deshalb ist der Standort im Naming fast unabdingbar.
Was für Ideen habt ihr, was nutzt ihr? Was für Anmerkungen habt ihr?
Generell kann ich natürlich irgendwas nehmen: aber möchte etwas nachhaltiges, logisches und sinnvolles.
Freue mich auf euer Feedback!
Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 524221
Url: https://administrator.de/contentid/524221
Ausgedruckt am: 25.11.2024 um 16:11 Uhr
10 Kommentare
Neuester Kommentar
Hi.
Das sieht doch schon richtig gut aus. Die Anforderung an der Stelle ist natürlich schon komplex und schnell verzettelt man sich hier in der Namensgebung.
Dein Favorit macht denke ich am meisten Sinn, nimmt man die Alternativen dagegen. Im Großen und Ganzen wird es natürlich schwer hier einen sinnvollen Vorschlag zu unterbreiten, denn Du hast Dir ja im Grunde über alles schon Gedanken gemacht.
Eine Frage zu den Domains hätte ich allerdings. Warum sollen die VLANs denn eigene Domains erhalten? Willst Du dann im Anschluss an einen Test den Server von Domain brise-test.intern nach brise-prod.intern migrieren? Warum die Testumgebung nicht auf den Firewalls entsprechend konfigurieren, bzw. ist das der Schritt, welcher noch in Planung ist?
Gruß
Radiogugu
Das sieht doch schon richtig gut aus. Die Anforderung an der Stelle ist natürlich schon komplex und schnell verzettelt man sich hier in der Namensgebung.
Dein Favorit macht denke ich am meisten Sinn, nimmt man die Alternativen dagegen. Im Großen und Ganzen wird es natürlich schwer hier einen sinnvollen Vorschlag zu unterbreiten, denn Du hast Dir ja im Grunde über alles schon Gedanken gemacht.
Eine Frage zu den Domains hätte ich allerdings. Warum sollen die VLANs denn eigene Domains erhalten? Willst Du dann im Anschluss an einen Test den Server von Domain brise-test.intern nach brise-prod.intern migrieren? Warum die Testumgebung nicht auf den Firewalls entsprechend konfigurieren, bzw. ist das der Schritt, welcher noch in Planung ist?
Gruß
Radiogugu
kleine Rand-Anmerkung: Mach die Nummer zweistellig.
Es passiert viel zu oft, das man da über die 9 kommt und dann sieht das wieder doof aus.
Ausserdem würde ich die Bindestriche rausnehmen.
Standorte bilde ich persönlich mit
[Land][Standortnummer] ab, also z.B de1dbc01, us3excas01 etc. Dann ist klar es geht um einen Server in Deutschland bzw USA, der steht im Standort 1\3, da läuft der DC-Cluster\ExchangeCAS drauf und der wievielte es ist.
Member kannst du ja wie gehabt auch anhängen.
Zuordnung von Standortnummern muss halt irgendwo gepflegt sein
Es passiert viel zu oft, das man da über die 9 kommt und dann sieht das wieder doof aus.
Ausserdem würde ich die Bindestriche rausnehmen.
Standorte bilde ich persönlich mit
[Land][Standortnummer] ab, also z.B de1dbc01, us3excas01 etc. Dann ist klar es geht um einen Server in Deutschland bzw USA, der steht im Standort 1\3, da läuft der DC-Cluster\ExchangeCAS drauf und der wievielte es ist.
Member kannst du ja wie gehabt auch anhängen.
Zuordnung von Standortnummern muss halt irgendwo gepflegt sein
Moin,
je nach Größe und Standorte eines Unternehmens ist es nicht einfach ein Schema zu finden. Wir nutzen Ländercode, Kürzel der Stadt, zwei Buchstaben für das Unternehmen und restlichen Zeichen zu maximalen Länge werden mit Nummern aufgefüllt. Diese ist natürlich fortlaufend.
Wir sind z.B. inzwischen übergegangen im Namen nicht mehr Details zum evtl. Service (z.B. DC oder Exchange) unterzubringen. Hat einfach den Hintergrund, dass die meisten Angriffe aus dem Intranet erfolgen und somit nicht am Namen erkennbar ist, was auf dem Server läuft.
Gruß,
Dani
je nach Größe und Standorte eines Unternehmens ist es nicht einfach ein Schema zu finden. Wir nutzen Ländercode, Kürzel der Stadt, zwei Buchstaben für das Unternehmen und restlichen Zeichen zu maximalen Länge werden mit Nummern aufgefüllt. Diese ist natürlich fortlaufend.
Wir sind z.B. inzwischen übergegangen im Namen nicht mehr Details zum evtl. Service (z.B. DC oder Exchange) unterzubringen. Hat einfach den Hintergrund, dass die meisten Angriffe aus dem Intranet erfolgen und somit nicht am Namen erkennbar ist, was auf dem Server läuft.
Gruß,
Dani
Zitat von @radiogugu:
Eine Frage zu den Domains hätte ich allerdings. Warum sollen die VLANs denn eigene Domains erhalten? Willst Du dann im Anschluss an einen Test den Server von Domain brise-test.intern nach brise-prod.intern migrieren? Warum die Testumgebung nicht auf den Firewalls entsprechend konfigurieren, bzw. ist das der Schritt, welcher noch in Planung ist?
Eine Frage zu den Domains hätte ich allerdings. Warum sollen die VLANs denn eigene Domains erhalten? Willst Du dann im Anschluss an einen Test den Server von Domain brise-test.intern nach brise-prod.intern migrieren? Warum die Testumgebung nicht auf den Firewalls entsprechend konfigurieren, bzw. ist das der Schritt, welcher noch in Planung ist?
Für mich ist es generell sehr logisch das ich die verschiedenen Sektoren klar voneinander trenne - warum nicht auch bei der Domain?
Die Domains sollen auch gleichzeitig die Windows Domänen wiederspiegeln: wie genau das da tatsächlich aussieht ist noch nicht ganz klar, da die zentrale Authentifizierung derzeit in der Planung von jemandem mit etwas mehr Ahnung ist (u.A. wegen der Kompatibilität von Windows Server und Linux). Damit hatte ich bisher leider noch nicht genügend Berührungspunkte.
Wenn ich es richtig verstanden habe gibt es aber später verschiedene Domänen und Accounts:
BRISE-CORE (Für alle Mitarbeiter)
BRISE-TEST (Alle System-Administratoren)
BRISE-PROD (Nur für Mitarbeiter die den Betrieb der Umgebung kontrollieren)
BRISE-INFRA (System-Administratoren der Infrastruktur, falls das mal separiert wird)
Genau habe ich noch nicht den Vorteil gegenüber einfacher Gruppenrichtlinien präsentiert bekommen. Sicher ist aber, dass es sich immer um eigene Windows Server handelt die in dem zuständigen VLAN hängen. Jedes Segment bekommt eigenen DNS Server, eigenen DHCP, Authentifizierung.
Wenn ich es richtig in Erinnerung habe nennt sich sowas "Domain Forest" im AD.
Wie auch immer: Ziel ist es die Sicherheit und Verfügbarkeit zu erhöhen. Im Test Segment kann man so den Windows Server einfach mal abschießen (z.B. bei Updates), der Rest läuft weiter.
Wenn im PROD bei Patchen was schief geht: Infrastruktur und Core laufen noch, alle können sonst geregelt weiterarbeiten.
Bitte nagelt mich auf den kram nicht fest, da lasse ich mich grade beraten. Ich möchte bei der kommenden Namens-Umstellung das alles nur schon mit berücksichtigen.
Willst Du dann im Anschluss an einen Test den Server von Domain brise-test.intern nach brise-prod.intern migrieren?
Das wird es niemals geben. PROD und TEST können sich sowenig sehen wie das Wasserrohr die Stromleitung, wenn doch: dann knallt es. Es gibt in PROD nur Release Installationen über ein bestimmten Deployment / Build Server. Es gibt derzeit auch nur zwei Leute die in PROD Deployen dürfen, einer davon bin ich. Rest muss sich in TEST austoben.Die Segmentierung in VLANs/Zuständigkeiten hat übrigens noch nichts mit der IP Netz Segmentierung zu tun. Die sieht nochmal ganz anders aus: Web Server, Datenbanken, Fileshares (NFS z.B.), Load Balancer bekommen je Kunden teilweise eigene Netze. Je nachdem wie groß es im Einzelfall ist.
Es ist sicher viel Overhead, viel Wartungsaufwand: aber die Kunden sind bereit es auch zu bezahlen. Wir können immerhin sagen, dass wir die letzten 3-4 Jahren jede technische Störung und jeden Sicherheitsvorteil ohne eine Sekunde Ausfallzeit abgefedert haben. Das schätzen unsere Kunden auch.
Hoffe das war weitestgehend verständlich. Nur das Naming regt mich dezent auf: die Lösung kann ich nicht jede Woche ändern.
Bis dahin erstmal danke und Grüße!
Zitat von @Dani:
Wir sind z.B. inzwischen übergegangen im Namen nicht mehr Details zum evtl. Service (z.B. DC oder Exchange) unterzubringen. Hat einfach den Hintergrund, dass die meisten Angriffe aus dem Intranet erfolgen und somit nicht am Namen erkennbar ist, was auf dem Server läuft.
Wir sind z.B. inzwischen übergegangen im Namen nicht mehr Details zum evtl. Service (z.B. DC oder Exchange) unterzubringen. Hat einfach den Hintergrund, dass die meisten Angriffe aus dem Intranet erfolgen und somit nicht am Namen erkennbar ist, was auf dem Server läuft.
Ist definitiv ein Argument. Aber mir ist ein eindeutiger Name irgendwie lieber. Es bringt dem Angreifer in unserem Netzwerk sowieso nichts die Namen oder IPs zu kennen, der kommt sowieso nicht aus dem Kundenprojekt raus (Das einzige was am ende des Tages tatsächlich im Netz hängt). Das bestätigen uns unsere Daily-Security Scans.
Werde ich aber dennoch zur Diskussion hinzufügen.
Zitat von @SeaStorm:
kleine Rand-Anmerkung: Mach die Nummer zweistellig.
Es passiert viel zu oft, das man da über die 9 kommt und dann sieht das wieder doof aus.
Ausserdem würde ich die Bindestriche rausnehmen.
Hast du recht. Werde ich so einkippen und umsetzten: macht definitiv sinn - wenn auch nur fürs Auge. :Dkleine Rand-Anmerkung: Mach die Nummer zweistellig.
Es passiert viel zu oft, das man da über die 9 kommt und dann sieht das wieder doof aus.
Ausserdem würde ich die Bindestriche rausnehmen.
Standorte bilde ich persönlich mit
[Land][Standortnummer] ab, also z.B de1dbc01, us3excas01 etc. Dann ist klar es geht um einen Server in Deutschland bzw USA, der steht im Standort 1\3, da läuft der DC-Cluster\ExchangeCAS drauf und der wievielte es ist.
Member kannst du ja wie gehabt auch anhängen.
Zuordnung von Standortnummern muss halt irgendwo gepflegt sein
Ohne Bindestriche finde ich persönlich unleserlich, ist aber tatsächlich hier eine aktive Diskussion (Alleine wegen den maximalen Zeichen). Werde dem mal ein Vote von dir dazu geben. ;)[Land][Standortnummer] ab, also z.B de1dbc01, us3excas01 etc. Dann ist klar es geht um einen Server in Deutschland bzw USA, der steht im Standort 1\3, da läuft der DC-Cluster\ExchangeCAS drauf und der wievielte es ist.
Member kannst du ja wie gehabt auch anhängen.
Zuordnung von Standortnummern muss halt irgendwo gepflegt sein
Da wir unser Geschäfts sowieso nur in Deutschland betreiben macht ein "de1,de2,de3,de4" etc. weniger Sinn. Selbst wenn mal im Ausland: Dann findet sich ein passendes Kürzel, zumal wie fast ausschließlich Flughafenkennungen nutzen.
Moin,
Gruß,
Dani
Aber mir ist ein eindeutiger Name irgendwie lieber.
das ist eine persönliche Meinung. Das hat nichts in einer Entscheidungsfindung zu suchen. Denn du solltest bzw. musst im Interesse deines Arbeitsgeber handeln. Ich hätte lieber einen Skoda als Dienstwagen, muss mich aber mit einem Audi begnügen.Es bringt dem Angreifer in unserem Netzwerk sowieso nichts die Namen oder IPs zu kennen, der kommt sowieso nicht aus dem Kundenprojekt raus (Das einzige was am ende des Tages tatsächlich im Netz hängt). Das bestätigen uns unsere Daily-Security Scans.
Mit solchen Aussagen wäre ich vorsichtig. Solch und ähnliche Aussagen haben schon einige Leute getroffen. Der eine oder andere wurden schon eines besseren belehrt.Selbst wenn mal im Ausland: Dann findet sich ein passendes Kürzel, zumal wie fast ausschließlich Flughafenkennungen nutzen.
Bitte daran denken, dass ihr nur in Städte expandiert, welche einen IATA-Code haben. Gruß,
Dani
Hamburger? :D
"Arbeitsgeber" - bin ich glücklicherweise selber.
Es ist ja nicht nur das persönliche Empfinden, es hat durchaus einen Grund wie oben beschrieben.
Zumal ein Angreifer der solche Netzwerke knackt auch ohne DNS Namen herausfindet was darauf läuft und die Lücke ausnutzt insofern da eine ist.
100% Sicherheit gibt es nicht, glaube wir sind aber auf einem generell gutem Stand, durch externe geprüft.
Puh stimmt, so hießen die Dinger. Danke für die Aufklärung, man lernt nie aus. Vermutlich vergesse ich das aber auch wieder morgen. :D
Aber generell kann man schon sagen, dass jedes Rechenzentrum das vom Uplink infrage kommen würde in der Nähe einer Stadt mit IATA-Code sein wird. Und joa, bei den Büros muss man sich was ausdenken, sehe ich aber als weniger kritisch an.
Aber mir ist ein eindeutiger Name irgendwie lieber.
das ist eine persönliche Meinung. Das hat nichts in einer Entscheidungsfindung zu suchen. Denn du solltest bzw. musst im Interesse deines Arbeitsgeber handeln. Ich hätte lieber einen Skoda als Dienstwagen, muss mich aber mit einem Audi begnügen.Es ist ja nicht nur das persönliche Empfinden, es hat durchaus einen Grund wie oben beschrieben.
Zumal ein Angreifer der solche Netzwerke knackt auch ohne DNS Namen herausfindet was darauf läuft und die Lücke ausnutzt insofern da eine ist.
Es bringt dem Angreifer in unserem Netzwerk sowieso nichts die Namen oder IPs zu kennen, der kommt sowieso nicht aus dem Kundenprojekt raus (Das einzige was am ende des Tages tatsächlich im Netz hängt). Das bestätigen uns unsere Daily-Security Scans.
Mit solchen Aussagen wäre ich vorsichtig. Solch und ähnliche Aussagen haben schon einige Leute getroffen. Der eine oder andere wurden schon eines besseren belehrt.Selbst wenn mal im Ausland: Dann findet sich ein passendes Kürzel, zumal wie fast ausschließlich Flughafenkennungen nutzen.
Bitte daran denken, dass ihr nur in Städte expandiert, welche einen IATA-Code haben. Aber generell kann man schon sagen, dass jedes Rechenzentrum das vom Uplink infrage kommen würde in der Nähe einer Stadt mit IATA-Code sein wird. Und joa, bei den Büros muss man sich was ausdenken, sehe ich aber als weniger kritisch an.
Gruß,
Dani
Grüße zurück.Dani
Moin,
Gruß,
Dani
Hamburger? :D
Ne, wohne und arbeite im Südwesten der Republik (Richtung Bodensee).Gruß,
Dani
Zitat von @jokabo:
Zukünftig möchte ich für die 4 Bereiche 4 VLANs haben (ist derzeit in Arbeit) und je Scope eine Domain:
brise-prod.intern
brise-test.intern
brise-core.intern: graylog, jira, jenkins, repos.
brise-infra.intern: das sind sachen wie Switche, Firewall, Hardware Nodes, KVMoIP, IPMI...
Zukünftig möchte ich für die 4 Bereiche 4 VLANs haben (ist derzeit in Arbeit) und je Scope eine Domain:
brise-prod.intern
brise-test.intern
brise-core.intern: graylog, jira, jenkins, repos.
brise-infra.intern: das sind sachen wie Switche, Firewall, Hardware Nodes, KVMoIP, IPMI...
Ich würde core und infra zusammenlegen, KISS Prinzip.
Ansonsten würde ich eher sowas machen, dann kann man nämlich mit einem AD Forest arbeiten und die Admis brauchen nicht 20 Accounts..
prod.brise.intern
test.brise.intern
infra.brise.intern
Idealerweise ist die Domain eine richtige, evtl. mit de oder net oder so. Dann kann man später im Falle eines Falles auch routen, das Jahr 2020 und IPv6 lassen schön grüßen.
Die Kommunikation zwischen prod und test wird dabei vollständig verboten um auch mal bei Deployment Fehlern keine Probleme zwischen die Daten der Scopes zu verursachen. Auch aus Sicherheitsgründen.
Naja, ich würde mir hier mal Chef und/oder Puppet angucken und mich dann mal mit dem Thema CI/CD und Infrastructur as Code beschäftigen.
/Thomas
