dinsdag 26 augustus 2008

SharePoint Web Cluster

Het project zit niet echt mee. Blijkt de config dbase van SharePoint corrupt te zijn. Hierdoor is het onmogelijk om een nieuwe server toe te voegen aan de farm. Wat de verplaatsing van SharePoint meteen complex maakt. Namelijk zou je bij het toevoegen van een extra server in de farm de zaken kunnen repliceren en zodoende makkelijk weer de 'oude' sharepoint server kunnen ontkoppelen. Waardoor je sharepoint dus makkelijk 'fysiek' kunt verplaatsen. Helaas door de defecte config db is dit niet meer mogelijk. Waardoor al je settings en links meteen verdwenen zijn bij het opbouwen van een nieuwe farm. Voor de klant betekent dat ook alle 'hand-made' links opnieuw aangemaakt moeten worden binnen de diverse sites. Gelukkig is SharePoint wel zodanig door Microsoft gemaakt dat het wat betreft de security goed geregeld is. Deze permissions zijn namelijk geregeld in de content dbase. Dus het opnieuw aanmaken van je web applications en het vervolgens koppelen van de juiste content db, voila! Permissions are restored. Microsoft wordt gewoon steeds beter. Uiteraard moet je de application pools bij het aanmaken van de web applications ook opnieuw laten definiëren. Gelukkig draait de Back-end van SharePoint op het SQL Cluster, waardoor het maken van Backups van de dbases een formaliteit is. Daarnaast verhuizen we de back-end niet, enkel dus de WFE. (Web Front End). Na het opnieuw opzetten van de web applications en web parts, was sharepoint na een aantal uur weer in productie. Dus ruim voor de dead-line die was afgesproken, wanneer iedereen weer gebruik kon maken van sharepoint. Groot voordeel is nu ook dat bij het opzetten van het web cluster, enkel een node toevoeg aan de farm. Hiermee wordt alles gerepliceerd en voila! SharePoint geïmplementeerd in een load balance. Als je dbases maar intact zijn en niet corrupt dan is sharepoint 'just another day at the office'



dinsdag 19 augustus 2008

Windows 2003 NLB Web Cluster


Gisteren weer begonnen op het werk na een welverdiende vakantie. Direct zondag weer werkzaamheden uitvoeren op het DFS Cluster. Some things never change. Hoe dan ook. Direct in een meeting die dag. Meteen een implementatie plan geschreven voor het WEB cluster traject. Hierin het team gedefinieerd en de verantwoordelijkheden beschreven. Uiteraard gekoppeld aan een datum. Werkt gewoon erg prettig, kun je het overzicht bewaren en precies controleren wat de tijdsinspanningen zich bevinden. Bij de klant hebben we momenteel twee webservers, die separaat zaken afhandelen. Nu gaan we deze bundelen en een load balance creëren. Dus zodoende een NLB Cluster. Ideaal voor IIS omgevingen. Helaas zijn de webapplicaties die belangrijk zijn voor de klant, onbekend met de compatibiliteit van een Cluster. Om de beide webservers vrij te kunnen spelen om er vervolgens een cluster van te kunnen bouwen. Maken we een nieuwe IIS installatie aan op een andere server. Hier zullen alle applicaties worden geplaatst die op de webservers actief zijn. Dus kunnen we naast de LIVE omgeving een secundaire omgeving opbouwen. Deze zal na testen en goedkeuring de nieuwe tijdelijke LIVE omgeving worden. Dan kunnen we de webservers voorzien van een nieuwe installatie en een cluster opbouwen. Vervolgens zullen we de web applicaties weer migreren van de tijdelijke LIVE omgeving naar het web cluster. Uiteraard na testen en goedkeuring zullen de web apps permanent worden geplaatst op het web cluster. Omslachtig maar het is niet anders, omdat de klant geen budget heeft voor hardware en juist wil consolideren. Daarom loopt er hierna nog een mooi project op het gebied van virtualisatie, waarvan ik de architect wederom zal zijn, omdat ik min of meer verantwoordelijk ben voor de introductie van Virtualisatie bij de klant. Omdat ik weet dat het veel kosten zal besparen en op operationeel beheer zeker zal besparen.