Gå til innhold

Én website - flere servere


Anbefalte innlegg

Hei,

 

Jeg ønsker å kjøre én databasebasert website på flere lokasjoner på grunn av at denne er driftskritisk. Både website og database må ligge på 2 steder. Bruker SQL Server og IIS på Windows 2000.

 

DNS:

Slik jeg ser det holder det å legge inn 2 A-records mot forskjellige IP'er. Testet å legge inn dette i hosts fila på min maskin (mot 1 ip hvor det kjørte en webserver og 1 ip hvor det ikke kjørte en webserver) og både IE og Opera forstod utrolig nok at når de ikke fikk kontakt med den ene så brukte de den andre.

 

På samme måten får man jo flere a-records fra google.com f.eks.:

C:\>nslookup google.com

Name: google.com

Addresses: 216.239.37.99, 216.239.57.99, 216.239.39.99

 

Regner med at dette er en standard for http? Har noen en url/etc ang. dette? Eller ligger dette i den vanlige http/1.1 rfc'n (den er for lang til å lese igjennom hele;)?

 

Eneste problemet jeg hadde var om det faktisk kjører en webserver, men den ikke drifter den web'n jeg var ute etter, da fikk jeg "Bad Request (Invalid Hostname)". Er det noen måte jeg kan komme utenom dette? F.eks. få IIS til å "ignorere" requests med ugyldig hostname istedenfor å gi denne feilmeldingen?

 

Web:

Her ligger hovedproblemet i synkronisering av databaser, og også generering av interne nummere som MÅ være unike og MÅ/BØR være i riktig rekkefølge.

 

Har noen noe forslag til hvordan dette bør gjøres? Evt. kan det gjøres "manuelt" i koden min, men håper på noe bedre...

 

---

 

Håper på å få litt diskusjon og idéer her, selv om jeg ikke får noen "riktige svar". Må nok teste endel uansett...

Endret av jorn79
Lenke til kommentar
Videoannonse
Annonse
Jeg ønsker å kjøre én databasebasert website på flere lokasjoner på grunn av at denne er driftskritisk.  Både website og database må ligge på 2 steder. Bruker SQL Server og IIS på Windows 2000.

 

Web:

Her ligger hovedproblemet i synkronisering av databaser, og også generering av interne nummere som MÅ være unike og MÅ/BØR være i riktig rekkefølge.

 

Har noen noe forslag til hvordan dette bør gjøres? Evt. kan det gjøres "manuelt" i koden min, men håper på noe bedre...

Nå det gjelder DNS-oppsettet for webserverene så vet jeg dessverre ikke nok for å kunne hjelpe deg.

 

Når det gjelder SQL Server så kommer jeg i farten på to løsninger (det finnes sikkert mange andre).

 

1. Microsoft Cluster Service:

 

Jeg har aldri sett eller prøvd denne løsningen selv, rett og slett fordi den er ALT FOR dyr. Derfor har jeg selfølgelig ikke noe detaljkunnskap om emnet.

 

Fra www.microsoft.com (nesten helt neders på siden).

High-Availability Databases with Microsoft Cluster Service

 

SQL Server Enterprise Edition offers fault tolerance and high availability by providing failover from one server to another when the first server fails or needs to be taken out of service for maintenance. The failover mechanism works as follows. Two Windows Server 2003 servers are configured as a cluster. These two servers can support two instances of SQL Server. Each server manages a partition of the application database. So far, this is just standard SQL Server technology.

 

With SQL Server Enterprise Edition, each server can be made a virtual server that continues to offer service, even if the underlying node is taken offline by a fault or for system maintenance. To achieve this, the SQL Server databases are placed on shared SCSI disks accessible to both servers. If one server fails, the other server takes ownership of the disks and restarts the failed server on the surviving node. The restarted server recovers the database and begins accepting client connections. For their part, clients reconnect to the virtual server when the primary server fails. A Windows 2000 Server feature, Microsoft Cluster Service, allows the virtual server name and IP address to migrate among the nodes, so that clients are unaware that the server has moved. Microsoft Cluster Service is available in Windows 2000 Server, as well as Windows Server 2003 Enterprise Edition and Windows Server 2003 Datacenter Server.

 

SQL Server Enterprise Edition provides native setup support to set up virtual servers. After configuration, the virtual servers look just like any other server in the network, except that they can tolerate hardware failures. See Figure 10.

 

 

2. SQL Server replikering

 

Dette er nok den enkleste og billigste løsningen å sette opp siden den bare krever en ekstra server (HW+SW).

 

SQL Server har veldig gode replikeringsfunksjoner. Bruker det selv på et system med brukere i flere land, hvor det står en server pr. lokasjon som replikeres med 10 minuttes intervaller. Det fungerer som bare søren!!

 

Det er selvfølgelig flere ting en må tenke gjennom og ta hensyn til før en setter i gang. Her er noen:

 

1. Skal det være mulig å gjøre oppdateringer (insert, update, delete) på de foskjellige replikaene? SQL server tilbyr tre typer replikering: Merge, Transactional og Snapshot. Du kan lese mer om dem i Book Online.

2. Hvordan unngå konflikter i primærnøkler? Har du f.eks. tabeller som brukes for å hente ut neste nummer i en sekvens? Dette vil nemlig kreve endel omprogrammering?

3. Denne er viktig!! Bruker du Identity-kolonner? Hvis du gjør det så er det endel du må gjøre før du setter i gang. Bl.a. så må Identity egenskapen for feltene settes til Yes (Not For Replication). Hver tabell på hver server vil nemlig få egne identity-intervaller. Dette konfigurerer du i replication wizarden.

4. Fremmednøkler BØR settes til NOT FOR REPLICATION.

5. Eventueller triggere bør også settes til NOT FOR REPLICATION. Ellers vil de kjøres 2 ganger. Første gang når du gjør en insert, update eller delete, og andre gangen nå replikatoren oppdaterer recorden rundomkring på de forskjellige serverene.

 

Det er nok mye mer en bør tenke gjennom. Jge bommet fullstendig første gang jeg satte opp en Merge replikering (Merge replikering lar alle replikerte serverene være oppdaterbare). Heldigvis (og selvfølgelig) var dette på testservere.

 

Du får heller spørre etterhvert hvis du bestemmer deg for å bruke replikering.

Endret av kaffenils
Lenke til kommentar

Takk for svar! :)

 

Det blir nok replikering ja. Cluster Service er nok litt overkill og alt for dyrt...

 

I tillegg blir nok "admin" biten en egen website som ligger på kun 1 av serverene, slik at jeg ikke trenger toveis replikering av de fleste tabellene.

 

Problemet med "ordrenummer" som må være unikt og uten "hull" i serien blir nok et problem som ikke er til å unngå...

 

Jeg får bare sette igang å teste her :)

Lenke til kommentar
  • 5 uker senere...

I utgangspunktet ville jeg satt opp én master og én backup. Master replikerer til backup med jevne intervaller. Backup skal normalt aldri være i bruk. Hvis master feiler, så tar backup over. Når master er oppe og går igjen, må databasen fra backup replikeres til master. Slik eliminerer du synkroniseringsproblemer. Du bør ha som hovedregler at 1) backup skal aldri være i drift samtidig som master og 2) master skal aldri settes i drift igjen før databasen fra backup har blitt replikert tilbake.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...