Nieuwe methode voor netwerkdocumentatie

[Anoniem: 229065]

Beste mensen,

Als netwerkbeheerder loop ik al enige tijd met ideeen om op een nieuwe gestandaardiseerde methode netwerken te gaan documenteren.

Op dit moment zijn er geen standaard voor documentatie, niet echt tenminste. De meeste mensen hebben maar halve documentatie: lijstjes van IP-adressen, lijstjes van wachtwoorden, een Visio tekening van verbindingen en een inventory van hardware en software. Als 1 server uitvalt kun je niet aflezen wat dat voor gevolgen heeft voor je netwerk.

Mijn idee is om op verschillende niveau's afhankelijkheden te gaan documenteren. Een applicatie op een desktop heeft een afhankelijkheid met een database op een server, bijvoorbeeld. Door dit soort afhankelijkheden te documenteren kun je zien 'wat aan elkaar vast zit'. Vervang je de database-server dan weet je welke problemen je kunt verwachten want je kunt zien wat er allemaal aan vast zit.

Er bestaan al standaard tekenmethodes om afhankelijkheden te documenteren. In mijn ideaal-beeld zou je een applicaties (bijvoorbeeld een boekhoudpakket) als module kunnen plaatsen in je documentatie en daarna de afhankelijkheden als touwtjes kunnen koppelen. De totale documentatie zou dan op meerdere niveau's kunnen plaatsvinden: netwerkniveau (afhankelijkheden routers, dns-servers), applicatie niveau (database, exchange-servers, client software) en wellicht zelfs op user-niveau (welke users gebruiken welke plotter, printers). Je zou ook op zo'n blokje kunnen doorklikken en verder kunnen inzoomen.

Zijn er mensen die weten of dit al bestaat of zin hebben om zoiets te ontwikkelen (buiten dit forum)?

Robert Haerkens
Native networks

[ Voor 3% gewijzigd door Anoniem: 229065 op 11-08-2007 12:29 ]

[Equator]

Een goed CMDB design (en die zijn er genoeg) heeft de afhankelijkheden ook ingebouwd. Dus als een switch uitfikt, dan kan je hierin zien dat de servers verbonden met deze switch ook offline staan.
En voor elk van die server zijn er weer bepaalde applicaties/services die niet werken.. etc..

Documenteren van een Netwerk doe je imo op een paar manieren.
- Overzichts tekening (Visio) hoe welk touwtje aan welk component vast zit. Voor bepaalde netwerk flows.
- Duidelijk overzicht / DB met IP adressen (vaste adressen wel te verstaan)
- Een CMDB met al je assets met afhankelijkheden.

Zo'n projectje waar je het over hebt, zie ik niet 1,2 3 brood in hier op GoT. Ik zet het topic daarom even op slot, en ga even in overleg met mijn mede moderators. U hoort nog van mij

[Equator]

Oke, na enig overleg en heen en weer gemail gaat dit topic weer open: Echter puur voor de waarde van de discussie. Projecten opstarten lijkt me geen goed idee.

Wat de TopicStarter eigenlijk zoekt is een soort Correlatie systeem waarin afhankelijkheden (tussen componenten en services) ervoor zorgen dat bij uitval meteen duidelijk wordt wat hier door geaffecteerd is. Nogmaals, en wellicht ten overvloede denk ik dat een correct ingevulde en bijgehouden CMDB hier als basis voor kan dienen.

Maar goed: de discussie kan losbreken

[nextware]

Inderdaad lijkt mij een CMDB de beste optie om hiermee aan de slag te gaan.
Daarbij hebben wij, naast een uitgebreide CMDB, ook diverse documenten en tekeningen los bewaard waarin alles staat wat er gebeurd als er een switch uitvalt. Deze hangen ook bij ons aan de muur.
Als dus echt de pleuris uitbreekt, hebben we het in ieder geval nog op papier staan

[TrailBlazer]

toen ik bij een provider werkte hebben ze dat geprobeerd met het product netcool. Toen ze echter zagen hoe ingewikkeld het netwerk eruitzag hebben ze dat meteen opgegeven. dit kwam er mede door omdat geen enkel database gelinked was met elkaar. Ook is het werken met redundantie bijzonder lastig je moet dan namelijk extreem veel intelligentie in het systeem proggen. Grote kans dat dit lastiger/duurder om dit systeem te onderhouden is dan een skilled operator neer te zetten.
Mischien is het te doen met een klein en simpel netwerk maar als er veel redundantie inzit.

Zo heeft bij ons elke distributie switch twee uplinks met ieder twee kabels naar de coreswitches. Deze coreswitches hebben beide redundante processor kaarten. Sterft er een kaart af niks aan de hand een uplink eraf geen probleem. Alleen in een heel uitzonderlijk geval heb je echt een probleem. Het nadeel van zo'n intelligent systeem is dat operator erop gaan vertrouwen. Met als gevolg dat ze elk alarm weg gaan klikken omdat er toch niks aan de hand is want dan zegt het systeem het wel met een rood schermpje.

[ Voor 38% gewijzigd door TrailBlazer op 10-08-2007 10:33 ]

[Anoniem: 229065]

Wij beheren netwerken van vele bedrijven. Dus documentatie is veel belangrijker dan een goede beheerder die alles in zijn hoofd heeft. Er komt altijd een grens aan wat je kunt doorzien. Ik denk dat er nog niet zo'n dergelijke documentatie is omdat netwerkbeheer in het verleden relatief simpel was. Het beheer komt echter op steeds abstracter niveau (van disks, drivers, dhcp, dns) naar Activedirectory, serverrollen, virtualisatie, etc. Dus documentatie zou ook abstracter moeten: van PC'tjes en printertjes en netwerkkabeltjes in Visio naar objecten die verbonden zijn.

Vergelijk het met chips en electronica schema's. Er staan wel veel lijntjes (verbindingen) op tussen alle componenten maar je kunt er wel elke fout uithalen en zelfs simuleren. Met zo'n model voor netwerken zou je een netwerk ook kunnen simuleren. Simuleren wat er gebeurd als je een server vervangt bijvoorbeeld. Het gaat mij echt niet alleen om noodscenario's. Als je een server gaat vervangen wie heeft er dan een goed overzicht van wat er allemaal op draait en wat er allemaal van afhangt.
Als een fabrikant van een applicaties nou een blokje zou aanleveren met daarop de lijntjes die je moet verbinden (ze hebben een database nodig, een fileserver, een open poort op een firewall, etc.) dan ben je toch op een veel intelligentere methode aan het netwerk-ontwerpen en je kunt ze vooraf 'simuleren'. Zoals een electronica tekenpakket de lijntjes in je schema kan nalopen of ze allemaal verbonden zijn.

En stel dat je alles gedocumenteerd hebt; als je dan een netwerk component vervangt moet je feitelijk gewoon alle verbindingen ermee herstellen. Daar leid je dus zo de werkzaamheden uit af.

Mijn idee is iets zoals in dit schema:

[ Voor 27% gewijzigd door Anoniem: 229065 op 11-08-2007 12:23 ]

[Anoniem: 57365]

Equator schreef op vrijdag 10 augustus 2007 @ 07:52:
Oke, na enig overleg en heen en weer gemail gaat dit topic weer open: Echter puur voor de waarde van de discussie. Projecten opstarten lijkt me geen goed idee.

Wat de TopicStarter eigenlijk zoekt is een soort Correlatie systeem waarin afhankelijkheden (tussen componenten en services) ervoor zorgen dat bij uitval meteen duidelijk wordt wat hier door geaffecteerd is. Nogmaals, en wellicht ten overvloede denk ik dat een correct ingevulde en bijgehouden CMDB hier als basis voor kan dienen.

Maar goed: de discussie kan losbreken

Een kloppende CMDB is altijd de basis. Zoals je al aangaf zijn er pakketten, die deze relaties aankunnen, echter is dit wel allemaal een handmatige actie en zal je de relaties dus zelf moeten maken en vooral bijhouden.

Ik ken dit soort logica vnl in monitoring tools en ook daar is het een handmatige actie om een applicatie en zijn afhankelijkheden te bouwen zodat het geheel als 1 proces gemonitord kan worden. Juist het handmatige hierin is het probleem en vooral omdat het redelijk wat extra werk kost om het goed bij te houden.
Zolang je alles zelf beheert (zeg maar intern bij een bedrijf werkt en een beperkt aantal mensen voor alle onderdelen verantwoordelijk zijn), is het nog wel te doen. Maar als je afhankelijk bent van meerdere partijen wordt dat toch wel erg problematisch...

[Wirehead]

Qua zien wanneer er iets uitvalt kan je je ook baseren op nagios. Je kan je topologie uitbouwen in de nagios map en dan per ring / tree gaan sorteren.

[Rolfie]

Anoniem: 229065 schreef op zaterdag 11 augustus 2007 @ 12:11:
....

Of wel een grafische CMDB. In een kleine schaal is dit nog wel te doen, maar in een grote omgeving gaat dit visio technisch wat lastiger worden. Helemaal als het over verschillende afdelingen gaat. 1 voor de DB, 1 voor de MS server, 1 voor de unix SMTP server, networking, firewall beheer en de ontwikkelaars. Of wel je stopt het in een goede CMDB.
Ik weet dat je dit ook allemaal aan HPOV kan koppelen. Zo krijg je inderdaad een mooi overzicht dat als er een server uitvalt, wat de gevolgen zijn. Maar uit een goede CMDB is dit ook alleemaal te halen.

[Gomez12]

Anoniem: 229065 schreef op zaterdag 11 augustus 2007 @ 12:11:
Wij beheren netwerken van vele bedrijven. Dus documentatie is veel belangrijker dan een goede beheerder die alles in zijn hoofd heeft. Er komt altijd een grens aan wat je kunt doorzien. Ik denk dat er nog niet zo'n dergelijke documentatie is omdat netwerkbeheer in het verleden relatief simpel was. Het beheer komt echter op steeds abstracter niveau (van disks, drivers, dhcp, dns) naar Activedirectory, serverrollen, virtualisatie, etc. Dus documentatie zou ook abstracter moeten: van PC'tjes en printertjes en netwerkkabeltjes in Visio naar objecten die verbonden zijn.

Vergelijk het met chips en electronica schema's. Er staan wel veel lijntjes (verbindingen) op tussen alle componenten maar je kunt er wel elke fout uithalen en zelfs simuleren. Met zo'n model voor netwerken zou je een netwerk ook kunnen simuleren. Simuleren wat er gebeurd als je een server vervangt bijvoorbeeld. Het gaat mij echt niet alleen om noodscenario's. Als je een server gaat vervangen wie heeft er dan een goed overzicht van wat er allemaal op draait en wat er allemaal van afhangt.
Als een fabrikant van een applicaties nou een blokje zou aanleveren met daarop de lijntjes die je moet verbinden (ze hebben een database nodig, een fileserver, een open poort op een firewall, etc.) dan ben je toch op een veel intelligentere methode aan het netwerk-ontwerpen en je kunt ze vooraf 'simuleren'. Zoals een electronica tekenpakket de lijntjes in je schema kan nalopen of ze allemaal verbonden zijn.

En stel dat je alles gedocumenteerd hebt; als je dan een netwerk component vervangt moet je feitelijk gewoon alle verbindingen ermee herstellen. Daar leid je dus zo de werkzaamheden uit af.

Mijn idee is iets zoals in dit schema:

[afbeelding]

Ok, we hebben het over netwerken...
Dus heb ik nog een switch nodig (met vlans?).
We hebben nog iets nodig wat dns verzorgt(zodat ik weet wat de sqlserver en fileserver zijn ).
Hoeven de gebruikers nooit iets uit te printen ( oftewel printserver + printer ).
We zitten in PNS dus ik heb ook nog een authenticatie server nodig ( AD? ).
En de fileserver heeft nog een backup nodig, net zoals de sql-server.

Oh wacht, de app kan ook mail versturen dus is er weer een dependency op een mailapp, die weer een dependency heeft op een mailserver die weer een dependency heeft op de firewall.

Maak nu eens een schemaatje met 2 clients die 2 apps gebruiken die gescheiden zijn van elkaar en verwerk er voor de grap eens een citrix server server / terminal server in.

En probeer het dan eens uit te tekenen voor een kleine 100 clients / 15 apps en zie hoe duidelijk je overzicht wordt. En als je dit eenmaal hebt uitgetekend probeer het dan eens bij te houden...

Er zijn enkele netwerk controleprogrammaatje die dit soort dingen kunnen controleren, inclusief dependency's ( nagios bijv. ) maar over het algemeen kunnen die geen duidelijk schemaatjes maken omdat juist alles aan elkaar hangt. Waardoor het te veel info in 1 tekening wordt.

Vb. Zonder een authenticatie server kan een computer niet opstarten, maar na het opstarten van de app heb je alsnog enkele apps die continue inloggegevens controleren ( authenticatie server is dus nodig ) en je hebt apps waarbij je gewoon de authenticatie server tussen 09:00 en 16:00 kunt uitzetten ( reboots daargelaten ).

Denk dan nog eens aan redundantie etc.
Vb wij hebben 5 citrix servers, als er windows updates komen die wij mee willen pakken dan gebeurt dit gewoon over 5 dagen ( per dag 1 citrix server logins disablen ).
Wij hebben 2 fileservers die in principe identiek zijn aan elkaar ( op 1 wordt gebruikersdata geplaatst, op 2 worden erp gegevens geplaatst. 's nachts wordt het hele zooitje gescynchroniseerd. Kunnen wij er 1 uitzetten, met 1 dag voorbereiding wel ( dns van server1 naar ip-adres server2 laten gaan ) spontaan nee, dan is er echt een probleem)
Wij hebben 2 printservers draaien, hebben in principe dezelfde printers, dus zou je zeggen dat je via dns ook daar gewoon 1 van kan uitzetten met dns verwijzing naar server2. Maar wij hebben 1 app draaien die gewoon alleen maar op ip print. Dus hiervan valt echt wel een gedeelte uit als wij 1 printserver platgooien

Oftewel bij een groter netwerk wordt het een stuk ingewikkelder dan je eventjes in enkele kleine schemaatjes kan uitbeelden puur omdat je dan te maken gaat krijgen met redundancy / meerdere apps die rare eisen stellen etc.
Zo staat er bijvoorbeeld in onze netwerk documenhtatie dat 1 server niet uit mag als gebruiker x ingelogd is. Gebruiker x is al ongeveer 5 jaar uit dienst, maar was zo spraakmakend dat iedere nieuwe medewerker bij ons binnen 1 week weet wie gebruiker x was. En de huidige gebruikers van deze app zijn allemaal part-timers die wel elke maand lijken te veranderen. Dus blijkt de netwerk documentatie lekker met gebruiker x staan.

[TheBrain]

Er zijn een aantal tools die dit zeggen te doen. Hierbij zijn monitoring en documentatie geïntegreert. Ik zou het overigens willen beperken tot het niveau waar de gebruiker interactie mee heeft. Als een applicatie eruit ligt dan zijn er altijd wel users die daar last van hebben. Criterium is hoe belangrijk de applicatie is. Het kan best zijn dat er maar vijf gebruikers zijn van een applicatie maar als dat toevallig de facturatie is dan is het heel belangrijk dat die applicatie up and running blijft ook al is het bedrijf duizenden man groot.

Qua intelligente monitoring komt Netbotz van APC komt zo al bij me op.

Een andere benadering van hetzelfde probleem is door dashboards te bouwen. NimSoft heeft NimBUS waarmee dat heel eenvoudig kan. Je kan net zoveel levels maken als je zelf wil. Wij hebben zelf een aantal basis dashboards gemaakt op basis van vestigingen. Is er een probleem in een vestiging dan kan je doorklikken naar het niveau daaronder waar een aantal hoofdcomponenten staan etc. etc. totdat je bij een individuele server of switch terecht komt.

Voor meer dashboard voorbeelden kan je kijken op http://dashboardspy.com/ of http://www.enterprise-dashboard.com/

[ Voor 39% gewijzigd door TheBrain op 13-08-2007 22:38 . Reden: antwoord veel uitgebreider gemaakt ]

[ppl]

En dan hebben we het bedrijfskundige deel er nog niet eens bij betrokken
Ook bij gebruikers vindt je afhankelijkheden: als Kees op wat input van Truus zit te wachten terwijl Truus niet kan werken omdat er een netwerkswitch kapot is in het deel van het gebouw waar zij werkt dan heeft dit niet alleen effect op Truus maar ook op Kees. En zo kun je nog wel verder specificeren waardoor je het alleen maar complexer maakt en je het overzicht compleet kwijt bent. Leuk al die tools maar ik denk dat je ook vooral eens moet gaan kijken naar waar de grens ligt. Is het wel zo handig om echt allerlei afhankelijkheden vast te gaan leggen of volstaat het om alleen te documenteren dat server1 afhankelijk is van server2 ?

[Anoniem: 229065]

Ik ben dit Topic gestart en denk dat de meeste mensen het niet zien zitten. Bedankt voor jullie gedachten. Maar ik probeer het nog 1 keer

Er wordt vaak gezegd dat het te ingewikkeld zou worden. Maar dat mag toch feitelijk geen probleem zijn. Je moet op een 'abstract' niveau kijken wat afhankelijk is en verder niet. Voorbeeld: een CAD/CAM applicatie draait op Pc's, één PC is tevens licentieserver, symbolen staan in een SQL-database en de tekeningen op een fileserver.

In een visio schema van het netwerk(je) zou je alleen een paar pc's en een server zien met lijntjes ertussen. Maar je ziet niet de CAD/CAM applicatie. Alsof het geen onderdeel van het netwerk is als het geen hardware is.
Dat er pc's, switches en servers zijn geloof ik wel, maar één niveau hoger, welke applicaties zijn er nou en hoe zijn die geinstalleerd, waar draait wat en wat hoort bij elkaar? Als je zou tekenen dat een CAD/CAM applicaties uit objecten bestaat zoals client-software, database, filestorage en licentieserver en je zou op die manier je netwerk tekenen dan krijg je een heel ander beeld.

Nog 1 voorbeeld: ik maak een aanpassing om 1 reden (bijv. ik geef een gebruiker lokale administrator rechten voor een specifieke applicatie). Voor een tweede applicatie moet dat ook maar omdat dit al gedaan was hoeft het niet meer. Als ik dit niet noteer vergeet ik waarom ik ookal weer administrator rechten had gegeven. Dat kan ik eigenlijk alleen maar onthouden of als tekst opschrijven. Het zou toch mooi zijn als je in een netwerktekening zoiets als "lokale admin" rechten kon koppelen aan de applicatie die dat nodig heeft?
Dan zie ik ook dat als er geen enkele koppeling / afhankelijkheid meer is met die administrator-rechten (als de applicaties verwijderd zijn) dat ik die rechten kan weghalen.

Een netwerkschema is nog teveel opgebouwd uit hardware, andere zaken kun je er bijna niet in kwijt.

[ Voor 39% gewijzigd door Anoniem: 229065 op 15-08-2007 16:30 ]

[Bl@ckbird]

Wat je eigenlijk wil is een 3D omgeving creëren waar binnen je kunt navigeren.
Op de X/Y-as projecteer je een kaart / plattegrond waar je apparatuur kunt plaatsen.
( Hosts / server / switches / alles eigenlijk )
Dit kan een plattegrond zijn van een lokaal gebouw, maar ook een wereldkaart.

In de Z-as projecteren we de 7 lagen van het OSI Model of de 5 lagen van het TCP/IP Model.
Ik zou hier nog een 8e / 6e laag bij willen voegen en dat is de user.

Netwerkverkeer stroomt door laag 7/8 --> 1, vervolgens door een aantal nodes
en vervolgens van laag 1 --> 7/8
Wanneer iets uit valt zie je meteen in welke laag dit zit en waar de effecten naar uitstralen.

Je kunt ook onderlinge "peers" selecteren.
Wanneer je wil zien hoeveel data, waar naar toe gaat, dan high light je laag 3 of 4.
(Netwerk of transport laag)
De dikte van de lijn kan bijvoorbeeld de momentele throughput visualiseren.
(Of een filmpje laten afspelen "over time.")

Wil je bijvoorbeeld onderlinge user afhankelijkheid inzichtelijk hebben, dan high light je laag 8.

Voor de bediening kan men multi-gesture touch screens gebruiken.
Is een fout gelokaliseerd, dan kan men in dit 3D scherm doorklikken
naar een traditionele 2D netwerk management GUI.

[TrailBlazer]

het gaat niet om hoe je het presenteert maar hoe je de intelligentie erin bouwt en onderhoudt.

[Anoniem: 57365]

TrailBlazer schreef op woensdag 15 augustus 2007 @ 18:36:
het gaat niet om hoe je het presenteert maar hoe je de intelligentie erin bouwt en onderhoudt.

ummm presentatie is zeker belangrijk. Veel intelligentie is handig, maar als een gebruiker van een pakket door alle mogelijkheden geen idee heeft hoe het werkt, is het als nog waardeloos.

Eenvoud in de interface, intelligentie daarachter en iedereen die er mee moet werken een zware cursus geven zodat er ook eenduidig meegewerkt en bijgehouden wordt.

[Bl@ckbird]

TrailBlazer schreef op woensdag 15 augustus 2007 @ 18:36:
het gaat niet om hoe je het presenteert maar hoe je de intelligentie erin bouwt en onderhoudt.

De intelligentie van netwerk management pakketten wordt steeds beter, omdat netwerk management informatie steeds fijner gecorreleerd wordt.

Natuurlijk is het handig om een volledig redundant netwerk te hebben. Maar voor welke prijs?
Soms is het goedkoper dat er een switch op de plank ligt. Je moet dan nog wel weten,
dat er een switch is uitgevallen.

Router interface fe 0/1 van router B3 in gebouw C is down.
Fijn... Maar welke impact heeft dit voor de user?

Het probleem met netwerk management pakketten is, dat ze bijzonder snel erg complex worden
en je er een dagtaak aan hebt om ze te onderhouden. Je schiet je doel dan voorbij.

De computer met de grootste intelligentie is de mens. En de mens is grafisch ingesteld.
Vandaar dat veel engineers eerst tekeningetje maken, voordat ze zaken gaan configureren.

Het probleem is dat netwerken steeds complexer worden en dat tekenen wordt daardoor steeds lastiger.
( Deelgebieden zijn uit te tekenen, maar daarmee mis je weer het grotere plaatje. )
Hier probeer ik een oplossing voor aan te dragen.

[jvanhambelgium]

Dat zijn allemaal zaken waar wij ook de nodige uitdagingen aan ondervinden...en ook nog niet helemaal uit zijn.
oa virtualisatie maakt het er allemaal niet eenvoudiger op. "vroeger" had je een effectieve server die op een effectieve plaats stond;
Nu heb je vb 2 datacenter op 2 verschillende plaatsen waar bepaalde applicaties op een virtual-machine plots op een andere locatie tevoorschijn kunnen komen (gebruik makend van VMotion bijvoorbeeld) met gevolgens implicaties allerhande technische implicaties !
NIET evident om zulke zaken in real-time up-to-date te houden...

en het lijstje groeit maar he, virtual storage, virtuele routers, high-availability setups etc zijn allemaal technische ingrepen die je CMDB knap lastig kunnen maken.
Verder is service-modelling ook best knap lastig, wat is de business impact indien X of Y event voorkomt, definitie van service items etc.

...om grijs haar van te krijgen...

[TrailBlazer]

Bl@ckbird schreef op woensdag 15 augustus 2007 @ 22:08:
[...]


De intelligentie van netwerk management pakketten wordt steeds beter, omdat netwerk management informatie steeds fijner gecorreleerd wordt.

Natuurlijk is het handig om een volledig redundant netwerk te hebben. Maar voor welke prijs?
Soms is het goedkoper dat er een switch op de plank ligt. Je moet dan nog wel weten,
dat er een switch is uitgevallen.

9 van de 10 keer moeten wij een monteur aansturen om een switch te vervangen. Met als gevolg dat we een behoorlijke downtime hebben dus voor ons is redundantie vaak een noodzaak.

Router interface fe 0/1 van router B3 in gebouw C is down.
Fijn... Maar welke impact heeft dit voor de user?

Het probleem met netwerk management pakketten is, dat ze bijzonder snel erg complex worden
en je er een dagtaak aan hebt om ze te onderhouden. Je schiet je doel dan voorbij.

De computer met de grootste intelligentie is de mens. En de mens is grafisch ingesteld.
Vandaar dat veel engineers eerst tekeningetje maken, voordat ze zaken gaan configureren.

Het probleem is dat netwerken steeds complexer worden en dat tekenen wordt daardoor steeds lastiger.
( Deelgebieden zijn uit te tekenen, maar daarmee mis je weer het grotere plaatje. )
Hier probeer ik een oplossing voor aan te dragen.

Ik heb best een hoop verschillende netwerken getroubleshoot en ik was op een gegeven moment vaak sneller om mijn eigen tekening te maken dan te vetrouwen op de tekeningen die op het systeem stonden. Vaak waren deze tekeningen niet up to date of gewoon niet te vinden.
We maakten ook niet zelf de designs voor al die netwerken wel werkten we met een paar standaard regels en dat was vaak genoeg.

Bij de huidige toko waar ik werd worden wel overal tekeningen van gemaakt en zijn redelijk accuraat. Ik doe hier alleen geen troubleshooting.

[ Voor 3% gewijzigd door TrailBlazer op 16-08-2007 08:17 ]

[Anoniem: 229065]

Bl@ckbird schreef op woensdag 15 augustus 2007 @ 17:35:
Wat je eigenlijk wil is een 3D omgeving creëren waar binnen je kunt navigeren.
Op de X/Y-as projecteer je een kaart / plattegrond waar je apparatuur kunt plaatsen.
( Hosts / server / switches / alles eigenlijk )
...

In de Z-as projecteren we de 7 lagen van het OSI Model of de 5 lagen van het TCP/IP Model.
Ik zou hier nog een 8e / 6e laag bij willen voegen en dat is de user.

Netwerkverkeer stroomt door laag 7/8 --> 1, vervolgens door een aantal nodes
en vervolgens van laag 1 --> 7/8
..
Wil je bijvoorbeeld onderlinge user afhankelijkheid inzichtelijk hebben, dan high light je laag 8.

Ik vind dit idee wel goed. Verschillende lagen van het OSI-model vragen om verschillende soorten tekeningen. Voor de fysieke laag kun je volstaan met een visio-tekening met kabeltjes en computertjes maar daarin kun je geen "wie heeft administrator rechten" kwijt. Als je een tekenmodel bedenkt dat universeel genoeg is voor elke laag ben je een stuk verder. Een kabel tussen een PC en switch is een lijntje maar een security-groep die rechten geeft voor een bepaalde applicatie is ook een lijntje.

Ik denk echter dat je het altijd zelf moet tekenen en niet automatisch laten genereren want dan verlies het ontwerp zoals wij als mens er tegen aankijken en krijg je weer meer verbanden die irrelevant zijn.

Als ik iemand een symbool geef (op papier) van een nieuwe voor hem onbekende applicatie dan weet hij hoe hij die moet installeren door de lijntjes te verbinden (met een sql-server, een security-groep, een netwerkshare,etc)

Ik zou hier eens een opzet voor willen bedenken op papier. Weet iemand of je zoiets zou kunnen doen in een open-project op internet waar meer mensen aan kunnen meewerken? Als het op papier bestaat kan er wel een tool voor gemaakt of gebruikt worden.

[Gomez12]

Anoniem: 229065 schreef op donderdag 16 augustus 2007 @ 09:20:
[...]


Ik vind dit idee wel goed. Verschillende lagen van het OSI-model vragen om verschillende soorten tekeningen. Voor de fysieke laag kun je volstaan met een visio-tekening met kabeltjes en computertjes maar daarin kun je geen "wie heeft administrator rechten" kwijt. Als je een tekenmodel bedenkt dat universeel genoeg is voor elke laag ben je een stuk verder. Een kabel tussen een PC en switch is een lijntje maar een security-groep die rechten geeft voor een bepaalde applicatie is ook een lijntje.

Ik denk echter dat je het altijd zelf moet tekenen en niet automatisch laten genereren want dan verlies het ontwerp zoals wij als mens er tegen aankijken en krijg je weer meer verbanden die irrelevant zijn.

Op zich wel leuk bedacht, en vast ook wel werkbaar in kleine omgevingen, maar bij grotere omgevingen ga je echt totaal verschillende tekeningen krijgen die allemaal uitgebreid zullen zijn, allemaal crossreferences gaan hebben ( want als je server 1 eruit haalt, tref je gedeelte x van het netwerk, gedeelte y van de programma's, en gedeelte z van de gebruikers ).

En als ik gewoon naar de dagelijkse praktijk kijk waarin 9 van de 10 netwerkdocumentaties altijd verouderd/niet volledig zijn, sommige netwerkdocumentaties zo zijn opgesteld dat niemand er meer iets aan heeft. Ik zelf altijd als stelregel hanteer dat 90% van de netwerkdocumentatie 1x in de 5 jaar vanaf scratch herschreven kan worden ( anders doorwerkende fouten etc ).
Dan zie ik er weinig nut in om nog meer documentatie te maken die onvolledig is ( want beschrijft maar 1 gedeelte ) en die nog moeilijker bij te houden is.

Simpel alternatief wat wij nu proberen op te zetten voor apps / gebruikers is gewoon met uitgebreide scripting te werken die self-documenting is.
Een gebruiker toevoegen aan een script, de documentatie wordt automagisch aangepast.
Een app heeft local admin rechten nodig, script dit en het verschijnt automagisch in de documentatie.
Een fileserver verandert van naam, dit moet veranderd worden in een config file van de scripts en alle documentatie verandert automagisch mee.
Zal morgen even zoeken naar de site waar het concept vandaan komt.

In theorie zou je hiermee ook documentatie van een server kunnen maken ( op dit moment maakt hij alleen documentatie van een script ), het bevat geen leuke visio tekeningetjes, het bevat redelijk veel overbodige informatie, maar an sich werkt het principe best wel en het is altijd actueel.

Dus niemand hoeft bij ons dit soort info in de toekomst bij te houden ( miscchien ) alhoewel we altijd wel de simpele visio structuren blijven houden die we nu ook hebben naast onze netwerkdocumentatie ( plus het feit dat onze simpele visio diagrammetjes koppelingen hebben naar de auto-generated code zodat je een simpele overview hebt met de visio-diagrammen en je kan doorklikken naar de detail documentatie )