Andreas Bergman

Pre IIS 7 there was a option to create a new ApplicationPool from an existing, to version 7 this has disappeared from IIS Manager, but it has moved to powershell.

To copy a applicationpool, you only have to run:

import-module webadministration
copy IIS:\AppPools\OldPool IIS:\AppPools\NewPool -force

You might receive an error when loading the module, but you can ignore it. Happy copying!

Source(http://www.mcbsys.com/techblog/2011/06/copy-an-iis7-application-pool/)

Jag letade efter ett nytt antivirus till min flickvän, tidigare har jag testat NOD 32 och AVG, men jag var lite less på begränsade gratisprogram och tänkte att jag för en gång skull ska testa en betalmjukara. Efter att ha googlat lite så hittade jag http://www.mjukvara.se/Antivirus-Kaspersky och det lät ju bra. Så jag tog ner trialversionen för att testa.

Installationen var inget att orda om, det gick snabbt och enkelt, och inställningarna är självförklarande.

För något år sen så körde jag ett antivirus av Norton, och det var ju ingen höjdare, minst sagt! Men Kaspersky Internet Security 2011 märks knappt, datorn tuggar på och jag behöver knappt engagera mig, och det är ju hemskt skönt, finns så mycket annat som är roligt.

Eftersom Kaspersky Internet Security 2011 har inbyggt stöd mot phising, dvs hemsidebedrägeri så slipper jag oroa mig för att användaren klickar på fel länkar, eller laddar ner något korkat, för Kaspersky håller koll på datorn.

Nu rekommenderar jag Kaspersky Internet Security till all mina vänner, även om jag inte har en fet badge att visa när jag gjort ett test, så är jag sjukt nöjd med det här antiviruset.

Igår lärde jag mig en intressant om Microsoft Active Directory, nämligen att det är väldigt beroende av DNSen för att fungera, något som jag både kan tycka är smart och ganska dumt.

Uppenbarligen så är det så att en massa pekare om vart klienten ska leta efter saker finns i en DNZ zon som heter _msdcs som Microsoft skapar i DNSen för att hantera pekare till olika tjänster, som tex Active Directory. När man lägger till en klient i domänen så letar klienten efter subdomänen _msdcs.domännamnet.tld efter de pekare som behövs, bland andra hosten _ldap som ska finnas i sub-subdomänerna dc,_tcp med andra ord så slår den upp adressen _ldap._tcp.dc._msdcs.domänen.tld för att ta reda på vilken maskin som är DC för den aktuella domänen.

På TechNet finns en förteckning över alla records som behövs för att det ska fungera, vilket är bra att veta om man vill använda en extern DNS istället för Microsofts inbyggda.

Min gissning till att man valt att göra såhär är för att man dels ska kunna använda en externs DNS, men det har nog också med skalbarhet att göra, exakt hur, varken kan eller orkar jag ta upp nu.

Jag är en extrem nagiosfanboy, i princip alla system och verktyg som är baserade på nagios gör mig glad. Ett av de allra nyaste och i mitt tyckte, bland de bästa i Communitykategorin är Icinga.

Projektet är en fork av Nagios och många av utvecklarna har tidigare utvecklat delar för nagios men nu har man valt att bryta sig loss, som jag förstår det, mycket på grund av nagiosprojektets motsträvighet med att ta in communitypatchar.

En av de allra största förändringarna är det helt ombyggda WebbUIt och ett rejält förbättrat API. Men har även släppt en modul för att kunna komma åt sin övervakning via mobilen.

Tack vare att Icinga är baserat och helt kompatibelt med Nagios så finns det en uppsjö av plugins att välja på, allt från att hålla koll på förändringar i växelkursen till att övervaka sin ESX-farm.

Läs gärna mer på: www.icinga.org

Jag har under kvällen suttit och jobbat med min labbmiljö för webbkluster och har börjat skissa på ett koncept för att addera/ta bort webbhostar ur miljön dynamiskt.

Säg att en av siterna blir uppmärksammad i Expressen, och får 500% ökning av besökare, detta kommer garanterat att sänka de flesta miljöerna, då man för det mesta inte har råd att hålla hur mycket hårdvara som helst.

För att råda bot på detta kan man ha ett övervakningssystem som håller koll på hur belastningen över en eller flera servrar ser ut, om den slår i taket i mer än 10 minuter så exekveras ett script som startar en kloning av en server hos tex CityCloud. När den här servern startar upp så lägger den automatiskt till sig själv i webbklustret och last börjar balanseras ut till den här servern också. Om det här inte räcker så kan man klona ut en server till, tills man fått ner belastningen till en rimlig nivå.

När besöks peakarna är över och har återgått till ”normala” nivåer eller någon form av baseline så ordnar övervakningssystemet automatiskt så att servrarna stängs ner och tar bort dem ut klustret, samt raderar dem från CityCloud så de inte står och tickar pengar längre.

Det är vad jag gjort ikväll, vad har du gjort?

Jag har 2 teorier som jag just nu håller på att testa, de rör hur man borde bygga sitt webbkluster för att få maximal upptid och så liten påverkan som möjligt vid bortfall av en server.

Lösningarna ser i princip identiska ut, men skillnaden ligger i om PHP-hanteras av Apache2-modulen för PHP eller om man hanterar PHP via FastCGI. De bygger båda på öppenkällkod och är helt redundanta. I båda ingår också ett MySQL/MariaDB kluster men det finns inte detaljerat då det inte är mitt primära mål just nu.

Lösning 1, Lastbalanserare och X antal apache2maskiner.

I den schematiska bilden ovan är det 2 olika kluster som delar på samma databaskluster, i schemat är inte lastbalanserarna redundanta men det ska de vara. Om en webbserver faller bort i klustret kommer 50% av beräkningskraften att försvinna och vid ev. peak så kommer troligen ett stort antal av besökarna att lämna siten då den går väldigt långsamt, självklart förutsatt att besökarantalet är större än vad en enskild maskin klarar vid bortfallet. I övrigt så finns alla andra fördelar som ett kluster innebär, möjligheten till att ta ner en maskin för underhåll utan att driften av siten påverkas etc. Beräkningskapaciteten i det kluster som fortfarande har båda sina maskiner i drift påverkas inte.

Lösning 2, Lastbalanserare, X antal apache2maskiner och ett FastCGI kluster.

Fördelen med den här lösningen är att, förutsatt att det är likadan hårdvara som i Lösning 1, den presterar bättre på samma antal maskiner. Detta då alla krävande PHP-beräkningar skickas till ett eget kluster. Det innebär att bortfallet av en webbserver i något av klustret inte kommer att påverka prestandan lika mycket. Planerar man och dimensionerar FastCGI klustret rätt och låter två siter som har olika peakar och tider av hög belastning dela FastCGI kluster så kan de dela på samma kluster. Då kan vi överdimensionera klustret något utan att det har kapacitet som står oanvänd ofta.

Det tredje alternativet jag har är att ha ett enda superstort apache2kluster och låta det göra allt. Det kommer krävas väldigt många fler maskiner för det, och maskiner är som bekant en kostnad. Som komplement till både lösning 1 och 2 kan man dessutom ha en funktion som skapar maskiner on-demand i molnet, då behöver man bara ha igång de maskinerna vid peakar och högtrafik.

Planen och ambitionen är att jag ska skriva ett par inlägg i veckan här på Domainz, tillsammans med ett 40-tal andra proffsbloggare. Listan är lång och består av riktigt roliga namn! Känns hedrande att få sälla sig till den skaran ska jag säga.

Jag lovar att INTE skriva om SEO, Onlinemarknadsföring eller Socialamedier. Det kommer bli hardcore System Management, hur man bygger feta webbkluster, väljer webhotell och självklart en hel del om den gyllene graal; 100% upptid. Därav namnet på bloggen föresten, 100% upptid, för många en våt dröm, men för få utvalda en verklighet. Jag kommer avhandla hur man når dit, vad man ska tänka på, ev. fallgropar och självklart en hel del tekniknörderi!

Närmast på tur så står ett rejält inlägg om Monitoring, nämligen en mjukvara som heter Icinga och vad för spännande saker man kan göra med den.

Stay Tuned och håll i hatten!