2010/03/08
I had this very strange experience today. One of my clients invited me to a meeting with their provider of Disaster Recovery Solutions (from now on called “DRS”). I was there to explain the intricate details of Oracle backup, restore and recovery. “DRS” is a rather successful player in the field of cloud backups, primarily for the SMB segment. They have added database backups and Enterprise style disaster recovery solutions to their portfolio. Everything seems to be based on off-the-shelf products that “DRS” sell under their own brand. Fair enough, this is what commodity computing is all about.
What is not so fair is that the Oracle backup solution is a blast from the past, utilizing “ALTER TABLESPACE … BEGIN BACKUP;”. Yes, I kid you not. Also, “DRS” was (1) not aware of this and (2) did not understand that this was a bad thing. The net-net of the meeting was that “DRS” offered my client to run a recovery test on the database server (“I think I have done Oracle recovery once before”) to prove that they had a good handle on the situation.
I am not sure if I should laugh or cry. My client is in a bind and “DRS” is not helping by continuing to pretend that is something they know how to do.
The really interesting thing about this whole story is how it highlights the pedagogical challenge involved in explaining database backup and restore/recovery concepts. Most of the time the databases just works. It is very seldom that one has to perform any kind of recovery. On top of that, vendors like Microsoft provide sleek interfaces to their backup utilities. This fuels the illusion that database backup and restore/recovery is simple and not really different from regular sysadmin work.
Leave a Comment » | 
database, oracle, virtualisering | 
Permalink
Posted by ebraekke
2010/02/17
Cloud seminaret i dag 17. februar 2010 var en selsom opplevelse. Bare et par uker etter at Larry Ellison hadde harselert med begrepet Cloud, kjører det nye Oracle et Cloud seminar i Oslo. Utover en (1) skikkelig bra sesjon rundt definisjoner, så var det mye kjent – lese lite nytt – fra Oracle. Jeg antar at formålet var å vise at Oracle er “med” og at de har produkter og tjenester for alt som har med Cloud å gjøre. Det meste interessante var vel det som ikke ble sagt, nemlig utfordringen med norsk lov mht lagring av data. Det er jo ikke helt problemfritt å lagre kritiske kundedata eller backup utenfor landets grenser. I tillegg kommer utfordringer med jurisdiksjon. Jon Honeyball som bla er skribent i PCPRO har belyst problematikken med datasenter i EU, men eid av Microsoft/Azure. Dersom National Security Agency i USA krever data utlevert fra Azure i Irland, hva skjer da?
Enn så lenge minner situasjonen i Norge i dag på den vi hadde en del år tilbake rundt innføringen av ADSL. Telenor ville melke ferdig investeringene på ISDN før de kjørte ut ADSL. På samme måte ser vi nå at de store driftssentralene ikke fokuserer på Skyen fordi de kan tjene mer på det tradisjonelle hostingmarkedet. Tilbydere av dynamiske tjenester – slik som EngineYard (US) og Brightbox (UK) – er avhengig egen eller andres infrastruktur. Først når vi får Sky-basert infrastruktur som små selskaper kan kjøpe kapasitet fra, vil mindre og lettbente aktører være i stand til å tilby skreddersydde løsninger i segmentet Software as a Service/Platform as a Service. Hvem vil være først med Sky-basert infrastruktur i Norge?
Leave a Comment » | oracle, virtualisering | Permalink
Posted by ebraekke
2010/02/03
Har begynt å bruke Aptana for Ruby og Rails utvikling. Kombinert med Aptana Cloud er dette skikkelig flotte greier. Det er temmelig enkelt å “deploye” kode til skyen og du får et staging sait med på kjøpet.
Eneste utfordring er at du må redigere ./config/initializers/new_rails_defaults.rb og kommentere bort følgende linje for at deploy skal gå sin gang.
# ActionController::Routing.generate_best_match = false
Høyeste rails versjon støttet av Aptana Cloud er 2.3.3.
Jeg begynte å bli temmelig lei av alle forskjellige hosting løsninger rundt om. Alle måte mekkes og stelles på. Her er det bare å kjøre en deploy kommando (som er en slag wrapper rundt capistrano) og vips så er saiten din oppe og går.
Leave a Comment » | rails, virtualisering | Permalink
Posted by ebraekke
2009/06/08
Scalr (scalr.net) er en tjeneste på toppen av Amazon EC2. Det er et såkalt “self-healing” og “auto-scaling” rammeverk og leveres både som open source (gjør det selv) og en tjeneste. Tjenesten koster $50 i måneden og har i teorien (nesten) samme funksjonalitet som RightScale som koster $500 i måneden. Du må ha en konto med Amazon for å benytte Scalr. All bruk/trafikk blir belastet via Amazon som vanlig (i tillegg til de $50). Scalr har ikke tradisjonell support men et aktivt brukerforum på groups.google.com.
Scalr virker med alle Linux varianter, bare det er … Ubuntu 7.04.
Jeg har enda ikke fått utført grundige tester, men har likevel noen ting jeg vil nevne. Det er meget lett å rigge en farm i Scalr. Dersom rollene du ønsker å benytte finnes i katalogen (rails, php, mysql el) så kan en farm være operativ på mindre enn 10 minutter. En farm vil typisk bestå av en “reverse proxy” basert last-balanserer (benytter nginx), en eller flere applikasjons-roller (feks rails) og en eller to databasenoder (hvis to, konfigurert som “master-slave”).
I motsetnimg til feks EngineYard Solo, så laster du i utgangspunktet ikke ned din private ssh nøkkel. Fra kontrollpanelet i Scalr kan du starte en ssh sesjon mot serveren ved å klikke på et symbol som representerer serveren din. Dette starter en MindTerm applet. Det ser da ut som nedenfor.
Akkurat dette synes jeg er ganske tøft fordi det reduserer behovet for å distribuere nøklene til alle maskinene jeg jobber fra (i mitt tilfelle minst to). Du kan heldigvis laste ned nøklene (det er en per farm) og logge deg på vha ssh -i som vanlig for EC2 instanser, men for mer tilfeldige forbindelser holder det med Internettadgang og muligheten for å kjøre java-appletter.
Videre benytter Scalr seg av dns, dvs at servere registreres i dns. Dette kan være en fordel, det er lettere å jobbe med navn enn ip-adresser. Det kan også være et problem, da det knytter din EC2 farm til Scalr sin infrastruktur. Der har det vært utfordringer, inntil nylig hadde scalr sine dns-servere i ett og samme datasenter! Så foreløpig heller jeg mot skeptisk, men jeg ser selvsagt nytten av å ha navn å forholde meg til.
Det selv-helbredene aspektet av Scalr er det nok delte meninger om. For ikke lenge siden ble en haug med servere under Scalr paraplyen startet på nytt ved en feiltagelse. Det var høy temperatur i brukerforumet i tiden etterpå … Jeg har ikke hatt anlednng til å teste ut skalerings-funksjononen i Scalr. Definisjonen er enkel nok: ved oppstart angir du min og maks antall forekomster av en rolle (feks applikasjons-server) og kriteriet for oppstart av en ny forkomst (basert på “load average”).
Det er for tidlig å si om Scalr er noe jeg vil anbefale. Jeg synes allikevel at $50 er en lav pris å betale for å få innsyn i hvordan man kan lage robust automatikk rundt EC2. Inntil videre er dette en god nok grunn til å fortsette å bruke det.
Leave a Comment » | virtualisering | Permalink
Posted by ebraekke
