Vraag Geen downtime-uploads / terugdraaien in IIS


Ik weet niet zeker of dit de juiste manier is om deze vraag te stellen, maar dit is eigenlijk wat ik zou willen doen:

1.) Druk een wijzigingenset naar een site in IIS.
2.) Onderbreek de gebruikers niet.
3.) Kunnen moeiteloos terugdraaien.

Er zijn dus een paar dingen waarvan ik weet dat ze moeten gebeuren:

1.) Out of Proc-sessie - afgehandeld
2.) Out of Proc cache - behandeld

Dus de vragen die overblijven:
1.) Hoe kan ik voorkomen dat ik de gebruikers onderbreek? Als ik de bestanden gewoon naar de prullenbak upload, recycleert de app en duurt het 10+ seconden om weer online te komen
2.) Hoe rol ik moeiteloos terug?

Ik dacht dat een mogelijke oplossing zou zijn om twee sites op te zetten in IIS, een publieke en een private. Uploads gaan naar privé en worden opgewarmd. Na het opwarmen worden de sites geruild. Een terugdraaien betekent alleen om te wisselen naar privé zonder een upload.

Dit lijkt in theorie gezond, maar ik ben niet zeker van de mechanica. Om het even welke ideeën?


17
2018-03-19 14:15


oorsprong


@NickatUship: is er slechts 1 server waarop de website wordt gehost? En zo niet, de mogelijkheid om een ​​seconde toe te voegen? - MattB
@NickatUship: ook, in welke IIS-versie zit u? - MattB
We zouden dit mogelijk kunnen oplossen met onze loadbalancer - dat klopt. Ik hoopte iets op de server zelf te kunnen doen - het zou beter werken voor onze flow. We zijn op IIS 7. - ChickenMilkBomb
ik vraag me af of we wereldwijde URL-herschrijfregels kunnen gebruiken voor een zero downtime-implementatie 1) Rewrite * .domain.com naar * .arbitrarysiteA.com, een app in IIS 2.) upload naar * .arbitrarySiteB.com 3.) warm het op up 4.) schakel de rewrite naar * .siteB.com - ChickenMilkBomb


antwoorden:


Hier is hoe ik dit probleem zou benaderen - houd in gedachten dat ik dit nog niet eerder heb gedaan, het zijn gewoon concepten die ik een beetje heb uitgetest in mijn ontwikkelomgeving. Je zou in staat moeten zijn om een ​​behoorlijk robuust raamwerk op te zetten met deze en wat scripting in jouw taal naar keuze. In principe gaan we een ghosto load balancing-omgeving opzetten en gebruiken om te schakelen tussen de nieuwe site en de oude site.

Om het te kunnen instellen, heb je het volgende nodig:

Installeer ARR om mee te beginnen.

Stel de 3 websites in IIS in:

  • Website 1 zal de site zijn waar uw gebruikers daadwerkelijk verbinding mee maken, laten we zeggen http://192.168.1.1/. Dit is ook de ARR-site. Stel gewoon een lege map in waarnaar dit moet verwijzen en plaats deze in zijn eigen app-pool. Stel de app-pool zo in dat er geen time-out optreedt volgens deze instructies.
  • Website 2 en 3 zijn de sites die uw inhoud hosten. Deze moeten op hun eigen IP's zijn en door de manier waarop ARR werkt, op een andere poort dan website 1. Laten we zeggen dat ze dat zijn http://192.168.1.2:8080 en http://192.168.1.3:8080. Ze moeten ook in hun eigen app-pools staan ​​en verwijzen naar verschillende directory's in het bestandssysteem (maar beide mappen hebben meestal dezelfde inhoud)

Na het installeren van ARR komt er een nieuwe categorie in IIS Manager met de naam "Server Farms" - klik met de rechtermuisknop en maak een nieuwe farm.

  • geef het een naam die voor jou betekenisvol is
  • voeg Webserver 2 en Webserver 3 toe als servers - zorg ervoor dat u op de knop "geavanceerde instellingen" klikt, open de categorie "applicationRequestRouting" en wijzig de httpPort in 8080 voor elke server
  • Voltooi de wizard - u wordt gevraagd of u URL Rewrite-regels wilt maken - klik op Ja
  • U hebt nu een serverfarm - om de configuratie te voltooien, naar de farm te gaan en op de proxyconfiguratieknop te klikken - schakel 'reverse rewrite host in response headers' in en pas de wijzigingen toe
  • Ga in IIS-beheer naar de hoofdniveau-servercategorie en klik op de URL Rewrite-knop, er zal een regel zijn die is gemaakt voor uw boerderij
    • dubbelklik op de regel om naar de instellingen te gaan
    • open het vak Voorwaarden
    • voeg een nieuwe voorwaarde toe voor {SERVER_PORT} komt niet overeen met 8080
    • pas de wijzigingen toe

Op dit punt heb je de basis van wat we nodig hebben om je verzoek uit te voeren. Als je gaat naar http://192.168.1.1/ u krijgt uw website van website 1 of website 2, maar het zal volledig naadloos zijn dat er andere sites zijn.

Wat u nu kunt doen als u een nieuwe versie van uw toepassing wilt implementeren, is:

  • drainstop 1 van de servers in uw boerderij (in de hulpprogramma's voor serverfarms, ga naar "Monitoring en beheer", kies een server en kies "Maak server onbeschikbaar")
  • implementeer uw nieuwe versie van de site op het systeem dat offline is
  • opwarmen van de site die offline is met behulp van de alternatieve IP / poort
  • de site weer beschikbaar stellen voor de boerderij
  • herhaal het proces voor de andere server

De Web Deployment-tool komt in het spel wanneer je het hebt over het schrijven van dit alles. Het maakt het super eenvoudig om een ​​pakket voor uw toepassing te maken en dit vanaf de opdrachtregel te implementeren. U kunt het pakket ook eenvoudig terugdraaien als er problemen zijn. ARR is ook scriptbaar de ... gebruiken Microsoft.Web.Administration dll's.

Een ander ding - als u zich daadwerkelijk op Windows 2008 R2 (IIS 7.5) bevindt, bekijkt u de Toepassing Warmup module - het zou het opwarmgedeelte ook gemakkelijker voor u moeten maken.


28
2018-03-25 19:52



Geweldig - bedankt mat. +1 zelfs gewoon om dit allemaal op te lossen. Ik zal het onderzoeken en terug naar het bord gaan. - ChickenMilkBomb
Perfect .. misschien niet fool proof .. maar werk aan het onderzoeken - Vivek Kumbhar
Dit is HET antwoord voor zero downtime-implementaties van IIS-toepassingen. Ik heb een diepgaande zelfstudie geschreven over hoe dit te doen + PowerShell te automatiseren. - kavun


MattB sloeg het uit het water. +1 Ik beantwoord met meer details, maar ik ben niet van plan zijn punten te nemen. Ik zal toevoegen aan wat hij zei.

Ik heb een soortgelijke opzet als wat hij beschreef, en het werkt geweldig. ARR is de juiste keuze, zelfs op een enkele server.

Er zijn echter een paar dingen die ik zou toevoegen.

Maak de 2 sites, zoals Matt heeft aanbevolen. Noem ze zoiets als uwsite.com01 en yoursite.com02.

Maak 2 URL Rewrite-regels. Eén voor www.uwdomein.com en nog één voor staging.uwdomein.com. Gebruik voor de productie {HTTP_HOST} met een waarde van (^ www.yourdomain.com $) | (yourIP). (of wat voor binding u ook prefereert) Gebruik voor staging {HTTP_HOST} met een waarde van (^ staging.yourdomain.com $). Bel de regels yoursite.com en staging.yoursite.com.

Bind regel = uwsite.com naar site = uwsite.com01 en regel = staging.yoursite.com naar site = uwsite.com02.

Stel FTP in op staging.yoursite.com.

Productieverkeer gaat nu naar Regel = staging.yoursite.com en Site = yoursite.com01. Stupelen naar het tegenovergestelde.

Je kunt op elk moment inzetten voor enscenering, testen, pre-spinup, andere mensen laten testen, etc. Doe het gedurende de dag, het maakt niet uit. Implementeer elke keer naar hetzelfde FTP-account. Werkt prima met build-servers.

Als u dan klaar bent om live te gaan, maakt u gewoon drie wijzigingen: - Verplaats de FTP-binding van yoursite.com02 naar uwsite.com01 - verander URL Rewrite Regel yoursite.com om naar uwsite.com02 te verwijzen - verander URL Rewrite Rule staging.yoursite.com om naar yoursite.com01 te wijzen

Nu hebt u geen downtime, direct schakelen, met onmiddellijke terugdraaifunctie!

Je enige wat je moet overwegen, is de status van je uit-proces-sessie. Zorg ervoor dat uw statusserver beide site-ID's accepteert, zodat u tijdens de swap de sessiestatus niet verliest.

Merk ook op dat dit alleen een web is en geen database.

Gebruik de configuratie-editor voor scripting. Breng de gewenste wijzigingen aan en klik vervolgens op "Script genereren". Het geeft je C #, appcmd of AHAdmin-code.

Ik heb dit een aantal maanden op zijn plaats gehad met een frontend aan de webpagina om instanties om te wisselen en ik kijk nooit meer achterom. Het maakt implementaties zo verfrissend in vergelijking met traditionele implementaties.


10
2018-03-25 21:22



@Scott - bedankt voor de follow-up, goed om te weten wat ik heb gepost is geen algemene gekte omdat ik het nog nooit eerder heb gedaan. - MattB
Ik heb niet veel succes gehad met het aanbrengen van wijzigingen in URL Rewrite-regels zonder downtime te veroorzaken. Het grootste deel van de tijd is voor mij: elke wijziging in URL Rewrite-regels op high traffic-servers zal CPU tot 100% spinnen gedurende ~ 5-10 seconden, wat mogelijk time-outs en waargenomen traagheid van gebruikers kan veroorzaken. - kavun
@kavun Ja, daar is waarheid voor. Bij een versie-update in de afgelopen jaren begonnen URL Rewrite-regels op wereldniveau recycling van appdomain voor alle sites te veroorzaken. Dat was niet het geval. Dus als u ASP.NET-sites op dezelfde server hebt, kan dit een impact hebben. Als u echter alleen hiervoor een speciale ARR-server hebt, is de boete voor een appdomain-recyclering minimaal en kunt u nog steeds een goede oplossing als deze gebruiken. - Scott Forsyth - MVP