bla!zilla

Wenn der Datenbankserver für die Warenwirtschaft virenverseucht ist, dann hat der Kunde zwei Probleme: Einen virenverseuchten Datenbankserver und offenbar ein Sicherheitsproblem... Nimm statt Homeuserkram eine Enterprise MLC oder eine SLC. Software-RAID ist Müll. Für Tests oder Softwaremigrationen ganz lustig, aber für mehr nicht zu gebrauchen. Daher die dringende Empfehlung keine PCIe zu nehmen, sondern Disks. Das Quentchen Performance, dass die PCIe (theoretisch) schneller ist, verpufft in dem Server eh. Da hast du keinen Mehrwert. Du überlegst dir, das SAS RAID 1+0 durch ein SSD RAID 1 zu ersetzen? Was sagt der Kunde dazu? Ist ja immerhin sein System. btw: Ein DB Server ohne BBU?

Wie wäre es mal mit einem Sniffer gewesen? Ich kann mir kaum vorstellen, dass es an den Switches liegt. Nutzt ihr STP oder RSTP?

Ich glaube der Kunde hat andere Probleme als ein Software-RAID mit zwei SSDs... Vielleicht erstmal die anderen Baustellen lösen, bevor man eine neue Baustelle eröffnet. Zu deiner Frage: Für das Systemlaufwerk ist die SSD Quatsch. Für die Datenbank durchaus interessant. Ob es ein Software RAID sein muss, wage ich zu bezweifeln. Die IOPS verpuffen bei der Kiste eh.

Fibre-Channel ist per Protokoll abwärtskompatibel, die wirst das neue Storagesystem also auch an den alten Switches mit 2 GB FC fahren können. Sinnvoll ist das aber nicht. Solltest du anfangen FC-Switches in der Fabric zu mischen, so solltest du dir jemanden dazuholen, der sich damit auskennt. Da sind möglicherweise Probleme vorprogrammiert. Fibre-Channel ist auch heute noch alles andere als Plug 'n Play.

Die optimale Chunksize/ Stripesize hängt von deinen Anforderungen ab. Möchtest du MB/s oder IOPS? Wenn du MB/s haben möchtest, dann sollte die Chunksize kleiner sein, als die durchschnittliche IO Größe. Wenn du IOPS haben willst, dann sollte die Chunksize größer sein, als die durchschnittliche IO Größe. Deine durchschnittliche IO Größe kannst du per perfmon ermitteln. Stripesize = Chunksize x Anzahl der Platten.

Normalerweise müsste man jetzt mal ein paar Grundlagen vermitteln (Sektoren, Stripesize, Chunksize, Blockgröße Dateisystem etc.), aber das lassen wir mal. Über wie viele Platten reden wir hier? Wie groß ist das Array? Welche Chunksize und/ oder Stripesize setzt du ein. IMHO solltest du dir eher Gedanken über die Stripesize/ Chunksize Gedanken machen, nicht über die Blockgröße des Dateisystems.

Steht doch in meinem Beitrag: Im giaddr Feld steht die IP von dem IP-Interface des Switches, über den der DHCP Request empfangen wurde. Auf Basis dieses Feldes wählt der DHCP Server den passenden Scope. Um es vielleicht noch einfacher zu machen: Client macht einen DHCP Broadcast. Switch empfängt Broadcast aus VLAN XYZ. In diesem VLAN hat der Switch das IP Interface 172.16.1.1/24. Dies schreibt er in das giaddr Feld und schickt einen Unicast an den DHCP Server. Dieser checkt das giaddr Feld und wählt eine IP aus dem Scope 172.16.1.0/24 und schickt die Antwort per Unicast an den Switch. Dieser schickt dann eine DHCP Offer an den Client. Ist doch gar nicht so schwer...

Ja, die Last lieber über unterschiedliche Pfade verteilen, statt über Teams. Einzelne Links sind per MPIO besser auszulasten als wenige "dicke Leitungen".

Schau dir mal AKCP an. Didactum ist einer der Reseller dafür.

Dafür: Nichts. Dagegen: Vieles... Das taugt maximal als Spielwiese um ein grundlegendes Verständnis von iSCSI zu erhalten. Aber von einem Produktionseinsatz würde ich eher absehen. Kommt aber auch auf die Umgebung an.

Ich habe die Erfahrung gemacht, dass diese Labels nicht kleben bleiben, gerade im warmen Abluftstrom von Servern lösen die sich gerne. Hier ein paar Erfahrungen zu unterschiedlichen Labels.

ITIL ist ja nicht Projektmanagement, sondern beschäftigt sich mit IT Service Management. Hinsichtlich Projektmanagement ist sicherlich Prince2 interessant, aber auch klassische Projektmanagementzertifizierungen nach DIN 69901. Alternativ kannst du dir auch mal SCRUM oder KANBAN ansehen. Auch durchaus interessant im Hinblick auf Projekt- und Chancemanagement.

Dann wird dein Bruttogehalt wahrscheinlich so zwischen 60k und 65k liegen. Je nach monetärer Bewertung der Benefits. Durchaus okay für Berufserfahrung und Dortmund.

Alternativ sowas hier.

Warum soll das nach was aussehen? Willst du Führungen anbieten? Mach es so, dass es praktikabel ist. Bei großen Installationen haben sich eindeutige Bezeichnung an beiden Kabelenden und Dokumentation in einer Exceltabelle bewährt. Wie du die die eindeutige Bezeichnung aufbaust, bleibt wir überlassen. Denkbar wäre etwas in Form von: V04-P03-SRV0021 Verteiler 4, Patchfeld 3 zu Server 21.

Stelle in Lünen?

Zertifkate sind Schall und Rauch und sind meist nicht mehr als ein Türöffnet. Was du vorweisen musst ist konkrete Produkt-/ und Projekterfahrung. Eine freiberufliche Tätigkeit auf Dauer ist möglich, aber ich fürchte eher weniger im Supportbereich. Sowas würde ich nur dann anstreben, wenn es um hochwertige, beratungsintensive Dienstleistung geht. Da sind die Stundensätze hoch genug, um auch mal eine Durststrecke zu überbrücken. Im Supportbereich ist sowas nur interessant, wenn man langfristige Kontrakte mit einem Auftraggeber hat, oder man lässt sich über Personalvermittler verhökern. In meinen Augen ist das eher wenig erstrebenswert. Sehr löblicher Vorsatz. Grundsätzlich ist Projektmanagement- bzw. IT-Prozess-Knowhow immer ganz praktisch. Stichworte sind hier ITIL und Prince2. Des Weiteren solltest du dir überlegen in welche Richtung es gehen soll: Server, Client, Netzwerk oder was anderes. Wirklich sinnvoll ist es nur dann, wenn du in eine Richtung gehst. Auf mehreren Hochzeiten tanzen wird auf Dauer sehr schwer. Wenn du aus dem Client-Umfeld kommst, dann könntest du natürlich bleiben, aber dich eben weiterentwickeln. Stichwort z.B. Desktop-Virtualisierung, Application Delivery etc. Wichtig sind hier weniger Zertifikate als viel mehr Grundlagen. Wenn du über konkretes Knohow verfügst und dieses über Zertifikate nachweisen kannst, dann sollten auch Projekte kein Problem sein. Wenn du dann am Ball bleibst, ist das schon mal eine sehr gute Basis. Auf jeden Fall ist das eine mittel- bis langfristige Sache. Schnell ein paar Schulungen und Scheine absolvieren wird nicht wirklich nachhaltig sein.

Stichtwort: Locking. Kann entweder durch die Anwendung selber sein oder durch das System. Virenscanner prüfen zwar Dateien, erzeugen aber AFAIK keine Dateisystemlocks, da das File beim Öffnen gescannt wird und der der Datenstrom durch einen Filtertreiber gezogen wird. Hast du DFS im Einsatz? NTFS Objektüberwachung.

Alles eine Frage des Skripting-Knowhows. Alles was man mehr als ein Mal macht, sollte man automatisieren. Per se ist alles, wo Menschen hand anlegen müssen, fehleranfällig. Automatisierte Prozesse erzeugen immer den gleichen Output. Aber hey: Dein Arbeitegeber, die Umgebung wird von dir administriert, eine Regeln. Ein SAN ist erst einmal nur ein Netzwerk, ein Netzwerk von Speichergeräten. Was du suchst, sind offenbar Speichersysteme im Entry-Level Bereich. Ich kenne deine Umgebung, deinen Arbeitgeber und dein Budget nicht, aber um rudimentäre Erfahrungen zu sammeln, sollte es ein beliebiges Entry-Level NAS tun, dass Speicher auch per iSCSI exportieren kann. Diese Systeme liegen preislich i.d.R. noch deutlich unter dem, was ein Single- oder Dual-Controller iSCSI Speichersystem kostet. Des Weiteren solltest du dir geeignete Literatur besorgen, um dich in die Thematik einzulesen.

Meines Erachtens nach nicht. Höchstens in der Form, dass du bestimmte Tätigkeiten bei der Recovery automatisiert. Alles was du per Hand machen musst ist fehleranfällig.

Ganz schlechte Idee. Kein Forum, auch dieses hier, kann professionelle Beratung ersetzen. Wenn wir über Virtualisierung reden, dann ist Knohow aus dem Kompetenzfeldern Storage, Netzwerk und Serverinfrastruktur gefragt. Meiner Erfahrung krankt es an den ersten beiden Punkten, insbesondere beim Storage-Knowhow.

Es ist nicht eine Frage des Preises, sondern des Service Value (auch wenn der Begriff aus dem Dienstleistungsmanagement kommt). Die Kosten-Nutzen-Relation ist wichtig, immer mit dem Hinblick darauf, dass wir hier über Unternehmensdaten reden.

Dafür muss dieser aber als DHCP Relay fungieren und das muss aktiviert sein. Das DHCP Relay muss wissen, an welchen Server es die Pakete schicken soll (Stichwort ip-helper-address). Das muss also in der Konfiguration des Switches ersichtlich sein.

Abgefahren... du kannst ja mal berichten, was der Call ergeben hat. Persönliche Meinung: Offenbar ist BE immer noch das gleiche Bananenprodukt wie vor 10 Jahren. Reift beim Kunden...

Dann hol das mal schleunigst nach. Das sollten bei 70/30 (Read/ Write), im Schnitt 32K IOs, RAID 1+0 und konservativ mit 0% Cache Hit Ratio überschlagsweise so 1500 random IOPS sein. Vergiss es. Die P2000 nutzt nicht mehr die gleichen Platten wie die ProLiants. Bei der P4000 ist es nicht vorgesehen Platten zu erweitern, nur Boxen (Basis sind DL180 G6), die P6000, P9000 und P10000 haben ebenfalls keine ProLiant SAS Disks. Das mit dem Umbauen von Platten ist noch aus seligen MSA1x00/ MSA30 Zeiten. Theoretisch kannst du eine P2000 nutzen und eine MSA70 hinterhängen. Dort könntest du dann die 10k 2,5" ProLiant SAS Disks verwenden. Eine Alternative wäre der Umbau der Platten in MSA70 Enclosures und der Einsatz von HP ProLiant Servern mit DataCore. Die Frage ist: Ist es betriebswirtschaftlich sinnvoll Platten umzubauen? Wohl kaum... Ein zweites Storage für den Disaster-Recovery Fall ist nice, aber eigentlich nur dann, wenn du dazwischen einen synchronen oder asyncronen Spiegel hast. Damit hast du dann ein sehr niedriges RPO. Das RTO hängt davon ab, wie einfach der Failover und der Wiederanlauf ist. Ein zweites Storage, auf dem du Images oder Kopien der VMs ablegst ist eher witzlos. Die meisten DR Pläne, die eine derartiges Szenario vorsehen, haben oft ein relativ hohes RTO und RPO (abhängig von der Aktualität der Images). Achte lieber darauf, dass an dem Storage alles redundant ist, dass die HBA/ Netzwerkkarten redundant sind, die Anbindung redundant ist und du ein ordentliches SLA auf die Komponenten hast (4h vor Ort, besser Call-to-Repair). Um es der Geschäftsführung schmackhaft zu machen solltest du wissen, was es das Unternehmen kostet, wenn die IT eine Stunde steht.