Systemoppsett
Supported Cloud Storage Products
Kommunikasjon
Grunnleggende (SRC Basic):
Backup kommunikasjon går i det grunnleggende oppsettet direkte fra kundens backup agenter, gjennom USIT sine backup proxyer, og deretter inn i det sentrale backupsystemet. Dette oppsettet gir mulighet for backup av laptop/arbeidsstasjoner og servere.
I dette oppsettet er det kun software agenter som må installeres hos kunden, og det er veldig raskt og enkelt å komme i gang.
Backupdata i UH-BaaS lagres på datasystemer som er plassert i USIT sine datahaller i Norge.
Hva blir det tatt backup av ?
Edge ( Laptop og arbeidsstasjoner ):
Servere:
Utvidet (SRC Advanced):
Databaser:
Dette oppsettet er et tillegg til det grunnleggende oppsettet, men som tillegg kommer konfigurasjon for ulike database typer. Det er fremdeles kun snakk om software komponenter, men det er noe mer konfigurasjon basert på nødvendig oppsett for forskjellige typer av databaser. Installasjon av Commvault software for ulike database typer kan gjøres som push install påbygg til standard filsystem agent.
Properties for MSQL og Oracle databaser:
Storage:
Ett oppsett for backup av storage systemer er tilnærmet likt SRC Basic, men for de fleste lagringssystemer må det installeres en eller fler proxy server(e) (Data Access Node (DAN)) i kundens miljøer for å få tilgang til filområder som er delt ut fra lagringssystemene (NAS). For en rekke andre lagringssytemer finnes det egen Commvault agenter som defineres som pseudo-klienter i Commvault. Slike DAN servere er maskiner i kundens mijø der det blir installert en Commvault software komponent (filesystem agent) på lik linje som en vanlig server. For store lagringsystemer anbefaler vi flere DAN servere for økt performance og feiltoleranse for backup.
Virtuell:
Dette oppsettet består av tre Commvault komponenter for å håndtere backup og restore av virtuelle maskiner. Komponentene som må på plass for backup, og restore av virtuelle maskiner er en psudo VMware vcenter klient (VCSA) i Commvault systemet som styrer kommunikasjonen mellom VM clusteret og Virtuell Server Agent (VSA). VSA installasjonene er Windows baserte virtuelle maskiner, og kan benyttes også for å gjøre restore av enkeltfiler fra backup av virtuelle Windows gjestemaskiner.
Det må defineres 1 VCSA pr virtuelt cluster.
Man må ha minimum 1 VSA pr virtuellt cluster, men vi anbefaler minst 2 VSA (for lastbalansering og redundanse. I store VMware miljøer anbefaler vi ytterligere 2 VSA pr 2000 gjestemaskiner.
Under konfigurasjon må VSA installeres før man oppretter VCSA.
Dersom man skal gjøre restore av enkeltfiler fra virtuelle Linux gjestemaskiner må man i tillegg ha på plass en File Recovery Enabler (FRE).
Man må ha minimum 1 FRE pr. organisasjon dersom man har behov for å kunne gjøre restore av enkeltfiler fra virtuelle Linux gjestemaskiner.
FRE
Ved etablering av Commvault File Recovery Enabler etterspørres det informasjon
- CS Configuration:
- CS Client Name: uh-baas
- CS Hostname/IP: uh-baas.uio.no
- CS Username: Bruker som har rettigheter til å installere
- CS Password: Passord til bruker som har rettigheter til å installere
- Firewall Configuration - Indicate whether the CommServe system is behind a firewall and enter values for Option 1, Option 2, or Option 3:
- Is CS behind a firewall?: YES
- For Option 3, enter all of the following values:
[Option 3] Proxy Clientname: bu-cc4-eap01
-
[Option 3] Proxy Hostname: bu-cc4-eap01.uio.no
[Option 3] Proxy Port number: 8403
Commvault dokumentasjon:
Etablering av Commvault File Recovery Enabler (OVA)
Hva blir det tatt backup av ved backup av virtuelle systemer:
VMware:
Bakcup av gjestemaskiner bruker vmware infrastrukturen for å kunne ta backup. For at vi skal kunne ta backup må derfor vmware infrastrukturen være i stand til å at snapshot av hele den virtuelle gjestemaskinen. For store virtuelle gjestemaskiner anbefaler vi å bruke agentbasert backup for å unngå å belaste vmware infrastrukturen med å ta store snapshot.
Hva som er ansett for å være en stor virtuell gjestemaskin er individuelt pr virtuelt cluster, og hvor godt det er rustet til å ta snapshot. (I USIT sitt interne miljø velger vi ofte å benytte agentbasert backup for virtuelle gjestemaskiner som er over 1 TB).
Vmware lager ett snapshot, og det er dette snapshotet som danner grunnlaget for backup. Det vil si at dersom en gjestemaskin har virtuelle disker som er definert som "independent", så vil ikke disse diskene være med i snapshotet. Independent disker er ikke en del av vmware backup.
Default vil backup av virtuelle maskiner være at det tas backup av alle virtuelle gjestemaskiner i hele vmclusteret. Det kan ekskluderes maskiner basert på navn / regexp, og eventuelt bruk av vmware tags (må konfigureres pr virtuelt cluster).
NB: Dersom kunden har fler vmware cluster, og maskiner blir flyttet mellom ulike cluster vil ikke ekskludering (filtrering) basert på navn/regexp i backupsystemet for maskiner som ikke skal tas backup av følge med mellom de virtuelle clustrene.
Cloud:
Dette oppsettet er mer avansert på grunn av de mange forskjellige mulighetene som finnes for skybaserte tjenester. Felles for alle skybaserte tjenester er at det må installeres minst 1 Cloud Application Proxy (CAP).
I store miljøer anbefaler vi ytterligere 1 CAP pr 5000 named users som det skal tas backup av.
Maskinene som kjører CAP er Windows baserte virtuelle maskiner. CAP maskinene kommuniserer med MediaAgentene og plasseres som regel i det virtuelle miljøet til USIT, men CAP maskinene kan også plasseres i Kundens miljø. Restore av data ved bruk av CAP gjøres som regel sky-til-sky.
Skybaserte tjenester trenger brukertilgang med lese (backup) og skrive (restore) tilgang til skytjenesten. For å øke performance på backup/restore kan det være aktuelt å benytte flere skykontoer for å kunne parallelisere backupene. Vi anbefaler ytterligere 1 skykonto pr. 500 brukere det skal tas backup av opp til 2500 brukere, og deretter ytterligere 1 skykonto pr 1000 brukere.
Backup agenter
Commvault backup agenter er bygget opp med ett byggestensprinsipp der Filesystem Core er det grunnleggende. Filesystem Core er tilgjengelig for de aller fleste operatisystem. Når backupagenten for Filesystem Core er installert er det denne komponenten som håndterer kommunikasjonen og autorisasjon til de sentrale enhetene i Commvault.
Når Filesystem Core komponenten er installert kan man utføre påbygg av agenten. Påbygg av agenten kan gjøres enten under installasjonen der man installerer en pakke bestående av Filesystem Core sammen med andre komponenter. (F.eks Filesystem Core sammen med Filesystem, og MSSQL database agent.) Eller man kan legge til komponenter senere direkte fra backupsystemet ( push-install ).
Eksempelvis kan man tenke seg at man har en installasjon med Filesystem Core, Filesystem og MSSQL agent, men ønsker i tillegg å ta backup av Oracle databaser på samme maskin. I ett slikt tilfelle kan man gjøre en push-install av Oracle backup komponenten direkte fra backupsystemet.
Oppgradering og patching av installerte backupagenter gjøres som push-upgrade fra backupsystemet sentralt.
Skedulering av backup
Backup intervallene i UH-BaaS er satt opp i henhold til backup planer. Planene er satt for å spesifisere hvor lenge backupen skal lagres, hvilke intervaller backupen skal kjøres, hvor backup data skal lagres og hvilken RPO som skal gjelde for backupene.
Som standard er det satt 8 timers RPO for all backup i UH-BaaS. Backupene kjøres stort sett med ett intervall på 24 timer. Slik at for å kunne opprettholde 8 timers RPO er det i tillegg til backup kjøreingene angitt ett antall snapshots i løpet av hvert døgn.
Pris for backuptjenesten
Prisene for backuptjenestene beregnes ut fra kundens lisensforbruk, front-end størrelse, og hvor lang retentiontid som ønskes for backupen.
Det er definert servicenivåer for å etablere standard er for tjenesten. En kunde kan benytte flere servicenivå.
Prise for tjenesten er angitt her
UH-BaaS har funksjonalitet og kapasitet for air gap lagring og skrivebeskyttet (WORM) backup kopi. Slik funksjonalitet er ikke en del av standard tjenesten, men prises individuelt.
Etablering av ny kunde i UH-BaaS
Konfigurasjon med FEIDE
Når det er inngått en avtale om å etablere backup gjennom UH-BaaS, og det skal benyttes autorisasjon gjennom FEIDE må følgende utføres:
USIT:
USIT IT må kontakte lokal FEIDE administrator på USIT og åpne for at kunden kan benytte UH-BaaS tjenesten.
Kundens organisasjon må opprettes i Commvault
- Company name = organisasjonens norske lovlige navn
- Company alias settes til kundens Brønneøsyundregister organisasjonsnummer slik det fremkommer i FEIDE som eduPersonOrgDN:norEduOrgNIN
- Identity server FEIDE endres slik at Associated SMTP inkludeder mail domain som skal videresendes for autorisasjon i FEIDE
Kunde:
Kundens lokale FEIDE administrator må akseptere UH-BaaS som tjeneste.
Konfigurasjon med Azure AD
Når det er inngått en avtale om å etablere backup gjennom UH-BaaS, og det skal benyttes autorisasjon gjennom Azure AD må følgende utføres:
Commvault dokumentasjon, Azure som identity provider
Kunde:
IT organisasjon hos kunde må følge prosedyren som er beskrevet av Commvault punkt 1. a) - g). og sender Federated Metadata XML til backup-core@usit.uio.no
USIT:
USIT etablerer kunden i UH-BaaS ved å følge Commvault dokumentasjon punkt 2. a) - c) og sender SP Metadata XML fil til kunde sammen med Single sign-on url til kunde.
USIT gjør attribute mapping
- user.userprincipalname = user name
- user.mail = Email
Kunde:
IT organisasjon hos kunde følger prosedyren punkt 3. a) - d)
Nødvendig nettverksoppsett fra kunde
Backupløsningen benytter proxy servere for kommunikasjon mellom kundens nettverk og backup systemet. Det er ingen begrensninger i USIT nettverksoppsett på hvor trafikken skal komme fra eller gå til annet enn at det er sperret for alt annet enn TCP port 8403. Løsningen er tilgjengelig fra hele verden.
Trafikken vil gå gjennom en SSH kryptert TCP tunell som initieres fra klienten hos kunden.
Trafikken initieres på høy port på klienten mot TCP port 8403 på våre backup proxy servere.
Proxy serverne vil svare fra TCP port 8403 og til den høye TCP porten som klienten initierte trafikken med.
En firewall hos kunde må tillate at trafikk går ut fra deres nettverk til proxy serverne mot TCP port 8403, og firewallen må tillate at proxyene svarer med ESTABLISHED connection fra TCP port 8403 mot kundens klientmaskin.
Viktig: Dersom det er en firewall som gjør avansert traffic pattern analyse f.eks IPS eller Application control, og ikke kun en port firewall kan det være ytterligere krav som må tilfredsstilles på Kundens firewall systemer for å slippe trafikk gjennom firewallen.
Liste over Edge Access Proxy (EAP) servere:
| Servernavn | Port |
|---|---|
| bu-cc4-eap01.uio.no | tcp/8403 |
| bu-cc4-eap02.uio.no | tcp/8403 |