Hvordan lage og legge til Citrix XenServer Storage Repositories - Del 4


I den fjerde artikkelen i denne XenServer-serien vil lagringsløsninger bli diskutert. I likhet med nettverk er lagringsløsninger i XenServer ofte vanskelige å forstå i begynnelsen. Før du starter noen konfigurasjon, bør den nye terminologien og konseptene som er involvert i XenServer-lagring diskuteres.

Oppdatering: I mai 2016 lanserte Citrix den nye versjonen av XenServer 7-plattformen. For installasjon følg: Fersk installasjon av XenServer 7.

XenServer introduserer flere nye termer i listen over tradisjonelle lagringsterminologier. Selv om det alltid er viktig å forstå konseptene når du arbeider med et hvilket som helst IT-system, er lagring ikke på langt nær så viktig som den forrige artikkelen som dekker nettverkskonsepter. Imidlertid vil denne artikkelen fortsatt ta deg tid til å forklare og forsøke å klargjøre disse lagringskonseptene.

Det første du må huske på med XenServer-lagring er at vi har lagring for den faktiske XenServer-verten og så har vi også lagring for gjeste- eller virtuelle maskiner som skal kjøre på XenServer-verten. Konseptuelt er dette enkelt å forstå, men å administrere det kan være en skremmende oppgave hvis administratoren ikke er kjent med formålene med hver av lagringsaspektene.

Den første termen er kjent som 'SR' eller Storage Repository. Dette er uten tvil det viktigste begrepet i XenServer-lagring da det representerer det fysiske mediet som virtuelle maskindisker vil bli lagret og hentet til. Lagringslager kan være en hvilken som helst av flere forskjellige typer lagringssystemer, inkludert lokal lagring koblet fysisk til XenServer-verten, iSCSI/Fibre Channel LUN, NFS Network File Shares eller lagring på en Dell/NetApp-lagringsenhet.

Lagringslager kan deles eller dedikeres og kan støtte en rekke nyttige funksjoner som rask kloning, sparsom tildeling (lagring klargjort ettersom den virtuelle maskinen trenger det), og virtuelle diskbilder som kan endre størrelse (mer om disse senere).

Lagringslager, SR, er logisk koblet til en XenServer-vert med det som er kjent som en Physical Block Device, oftere referert til som ‘PBD’. PBD er ganske enkelt en referanse til et lagringssted. Disse PBD-objektene kan "plugges" til en XenServer-vert for å la den verten lese/skrive informasjon til det lagringsstedet.

Hensikten med Storage repositories er først og fremst å lagre Virtual Disk Image (VDI)-filer for den virtuelle maskinen. VDI-filer er flekker på en SR som har blitt tildelt til å holde operativsystem og andre filer for virtuell maskin som kjører på XenServer-verten. VDI-filer kan være en av flere forskjellige typer. Typen bestemmes av typen lagringssted.

Vanlige VDI-typer i XenServer er Logical Volumes (LV) administrert av Logical Volume Manager, Virtual Hard Disk (VHD), eller de kan være Logical Unit Numbers (LUN) på en Dell- eller NetApp-lagringsenhet. Merk: Denne artikkelen vil bruke LUN-er på en Dell-lagringsenhet.

Disse VDI-filene er logisk koblet til virtuelle maskiner gjennom et objekt kjent som en Virtual Block Device, ofte referert til som 'VBD'. Disse VBD-objektene kan kobles til virtuelle gjester som deretter lar gjestemaskinen få tilgang til dataene som er lagret i den aktuelle VDI-en på en respektive SR.

På samme måte som nettverk i XenServer, er det én ting å lese om lagring, men det å kunne se forholdet mellom hver av disse elementene stivner ofte konseptene. De vanlige diagrammene som brukes til å representere XenServer-lagringskonsepter forvirrer ofte nyere mennesker, da diagrammene ofte leses på en lineær måte. Nedenfor er et slikt bilde lånt fra Citrix.

Mange individer leser dette lineært fra venstre til høyre og tenker at hver del er en separat fysisk enhet. Dette er ikke tilfelle og fører ofte til mye forvirring om hvordan XenServer-lagring fungerer. Grafikken nedenfor forsøker å forklare konseptene på en mindre lineær, men mer pragmatisk måte.

Forhåpentligvis forvirrer ikke grafikken ovenfor enkeltpersoner om XenServer-lagring. Det andre bildet er et forsøk på å vise de logiske tilkoblingene (PBD og VBD) som brukes til å koble XenServere og gjester til ekstern lagring over én faktisk nettverkstilkobling.

Med konseptualiseringen ute av veien; konfigurasjonen kan begynne. Med tanke på den første artikkelen i denne serien, bruker denne veiledningen en Dell PS5500E iSCSI-lagringsenhet for lagring av diskene til den virtuelle maskinen (gjestene). Denne veiledningen vil ikke gå gjennom konfigurasjonen av Dell iSCSI-enheten.

Systemkonfigurasjon:

  1. XenServer 6.5 installert og lappet (del 1 av serien)
  2. Dell PS5500E iSCSI-enhet (andre iSCSI-enheter kan brukes, bare erstatte miljøinformasjon der det er nødvendig).
  3. XenServer nettverksgrensesnitt konfigurert (del 3 av serien).
  4. iSCSI-enhet og XenServer kan logisk se hverandre (via ping-verktøy).
  5. CIFS (SAMBA) Server som kjører og er vert for en andel av CD ISO-filer (ikke nødvendig, men veldig nyttig).

Opprettelse av Citrix XenServer Storage Repository

Denne første prosessen vil gå gjennom trinnene for å lage en programvare-iSCSI-initiator fra XenServer-verten til Dell PS5500E.

Denne spesielle LUN bruker Challenge-Handshake Authentication Protocol (CHAP) for å begrense tilgangen til iSCSI-volumet til visse autoriserte parter.

For å opprette lagringsdepotet vil en tradisjonell 'xe'-kommando forekomme. Riktig iSCSI-informasjon må innhentes før du oppretter Storage Repository.

Ved å sende 'sr-probe'-parameteren til 'xe'-verktøyet vil XenServer instruere en lagringsenhet for iSCSI IQN (iSCSI Qualified Name).

Den første kommandoen vil se intens ut til å begynne med, men den er ikke så ille som den ser ut.


xe sr-probe type=lvmoiscsi device-config:target=X.X.X.X device-config:chapuser="tecmint" device-config:chappassword="tecmint_chap"

Denne første kommandoen er nødvendig for å samle SCSI IQN for konfigurasjonen av Storage Repository. Før vi går videre, la oss ta en titt på alle delene av denne kommandoen.

  1. sr-probe – Brukes til å spørre iSCSI-enheten om informasjon om volumet som er opprettet for denne XenServer-verten.
  2. type= Brukes til å fortelle XenServer typen lagringssted. Dette vil variere avhengig av hvilket system som brukes. På grunn av bruken av Dell PS5500, brukes lvm over iSCSI i denne kommandoen. Pass på å endre for å passe til lagringsenhetstypen.
  3. device-config:target= Brukes til å fortelle XenServer hvilken iSCSI-enhet som skal spørres etter IP-adresse.
  4. device-config:chapuser= Dette brukes til å autentisere til iSCSI-enheten. I dette eksemplet har et iSCSI-volum blitt opprettet tidligere for brukeren «tecmint ». Ved å sende brukernavnet og passordet i denne kommandoen, vil iSCSI-enheten svare tilbake med nødvendig informasjon for å fullføre opprettelsen av lagringsdepotet.
  5. device-config:chappassword= Dette er passordet for CHAP-brukernavnet ovenfor.

Når kommandoen er skrevet inn og sendt, vil XenServer forsøke å logge på iSCSI-enheten og vil returnere noe informasjon som trengs for å faktisk legge til denne iSCSI-enheten som et lagringssted.

Nedenfor er hva testsystemet returnerte fra denne kommandoen.


Error code: SR_BACKEND_FAILURE_96
Error parameters: , The SCSIid parameter is missing or incorrect , <?xml version"1.0" ?>
<iscsi-target-iqns>
        <TGT>
                 <Index>
                              0
                 </Index>
                 <IPAddress>
                 </IPAddress>
                 <TargetIQN>
                              iqn.2001-05.com.equallogic:0-8a096-0d9a4ab02-46600020343560ef-xenct-xen2
                 </TargetIQN>
        </TGT>
        <TGT>
                 <Index>
                 
                 </Index>
                 <IPAddress>

                 </IPAddress>
                 <TargetIQN>

                 </TargetIQN>
        </TGT>
</iscsi-target-iqns>

Den uthevede delen her er kjent som iSCSI IQN. Dette er veldig viktig og er nødvendig for å bestemme SCSIid for lagringsdepotet. Med denne nye informasjonen kan den tidligere kommandoen endres for å få SCSIid.


xe sr-probe type=lvmoiscsi device-config:target=X.X.X.X device-config:targetIQN=iqn.2001-05.com.equallogic:0-8a0906-0d9a4ab02-46600020343560ef-xenct-xen2 device-config:chapuser="tecmint" device-config:chappassword="tecmint_chap"

Det eneste som er lagt til kommandoen er targetIQN-strofen. Ved å utstede denne nye kommandoen vil systemet svare med den siste informasjonen som trengs for å lage et iSCSI Storage Repository. Den siste informasjonen er SCSI-ID.


Error code: SR_BACKEND_FAILURE_107
Error parameters: , The SCSIid parameter is missing or incorrect , <?xml version"1.0" ?>
<iscsi-target>
        <LUN>
                 <vendor>
                        EQLOGIC
                 </vendor>
                 <serial>
                 </serial>
                 <LUNid>
                         0
                 </LUNid>
                 <size>
                         107379425280
                 </size>
                 <SCSIid>
                         36090a028b04a9a0def60353420006046
                 </SCSIid>
        </LUN>
</iscsi-target>

Fra dette tidspunktet er alle nødvendige deler for å lage et iSCSI Storage Repository tilgjengelig, og det er på tide å gi kommandoen for å legge til denne SR-en til denne XenServeren. Oppretting av Storage Repository fra den kombinerte informasjonen gjøres som følger:


xe sr-create name-label="Tecmint iSCSI Storage" type=lvmoiscsi content-type=user device-config:target=X.X.X.X device-config:port=3260 device-config:targetIQN=iqn.2001-05.com.equallogic:0-8a0906-0d9a4ab02-46600020343560ef-xenct-xen2 device-config:chapuser="tecmint" device-config:chappassword="tecmint_chap" device-config:SCSIid=36090a028b04a9a0def60353420006046

Hvis alt går bra, vil systemet koble til iSCSI-enheten og deretter returnere UUID til det nylig lagt til Storage Repository.


bea6caa4-ecab-8509-33a4-2cda2599fb75

UUID-utgangen er et godt tegn! Som med alle systemadministrasjonsoppgaver, er det alltid en god idé å bekrefte at kommandoen var vellykket. Dette kan oppnås med en annen 'xe'-kommando.


xe sr-list name-label="Tecmint iSCSI Storage"
Eksempelutgang

uuid ( RO)                 : bea6caa4-ecab-8509-33a4-2cda2599fb75
          name-label ( RW) : Tecmint iSCSI Storage
    name-description ( RW) :
                host ( RO) : xenct-xen2
                type ( RO) : lvmoiscsi
        content-type ( RO) : user

Fra CLI-utgangen har denne XenServeren koblet til Dell iSCSI-enheten og er klar til å lagre gjeste-VDI-filer.

Opprettelse av ISO Storage Repository

Den neste serien med trinn går gjennom prosessen med å lage et ISO-bibliotek. ISO-filer er vanligvis bilder av CD-installasjonsmedier.

Ved å lage et spesielt lagringssted for disse ISO-filene, kan installasjonen av nye gjester gjøres veldig raskt. Når en administrator ønsker å opprette en ny gjest, kan de ganske enkelt velge en av ISO-filene som finnes i dette ISO-biblioteket i stedet for å måtte legge en CD fysisk i en XenServer i bassenget.

Denne delen av veiledningen vil anta at brukeren har en fungerende SAMBA-server. Hvis en SAMBA-server ikke er konfigurert, kan du gjerne lese denne artikkelen om hvordan du fullfører denne oppgaven i Red Hat/Fedora (jeg vil ha en Debian SAMBA-serverguide i fremtiden):

  1. Konfigurer Samba Server for fildeling

Det første trinnet er å samle den nødvendige legitimasjonen og konfigurasjonsinformasjonen for SAMBA ISO-biblioteket. Når brukernavnet, passordet og tilkoblingsinformasjonen er tilgjengelig, kan en enkel 'xe'-kommandovariant brukes til å koble SAMBA-biblioteket til XenServeren.


xe-mount-iso-sr //<servername>/ISO -o username=<user>,password=<password>

Denne kommandoen vil ikke sende ut noe til skjermen med mindre den mislykkes. For å bekrefte at den faktisk monterte SAMBA ISO-andelen, utfør en annen 'xe'-kommando:


xe sr-list
Eksempelutgang

uuid ( RO)                 : 1fd75a51-10ee-41b9-9614-263edb3f40d6
          name-label ( RW) : Remote ISO Library on: //                  /ISO
    name-description ( RW) :
                host ( RO) : xenct-xen2
                type ( RO) : iso
        content-type ( RO) : iso

Denne XenServer-verten er nå konfigurert med både et iSCSI Storage Repository så vel som et CIFS ISO-bibliotek for å lagre installasjonsmedier for virtuelle maskiner (gjester).

De neste trinnene vil være å lage virtuelle maskiner og koble disse systemene til de riktige nettverkene fra den tidligere nettverksartikkelen.