Sådan oprettes og tilføjes Citrix XenServer Storage Repositories - Del 4


I den fjerde artikel i denne XenServer-serie diskuteres lagerløsninger. Ligesom netværk er lagringsløsninger i XenServer ofte vanskelige at forstå i starten. Før en konfiguration påbegyndes, bør den nye terminologi og koncepter, der er involveret i XenServer-lagring, diskuteres.

XenServer introducerer flere nye udtryk til den traditionelle liste over terminologilagring. Mens forståelse af begreberne altid er vigtigt, når du arbejder med ethvert it-system, er opbevaring næsten ikke så vigtig som den tidligere artikel, der dækker netværkskoncepter. Denne artikel tager dog stadig tid til at forklare og forsøge at afklare disse opbevaringskoncepter.

Den første ting at huske med XenServer-lagring er, at vi har lagerplads til den aktuelle XenServer-vært, og så har vi også lagerplads til gæst eller virtuelle maskiner, der kører på XenServer-værten. Konceptuelt er dette let at forstå, men styring af det kan være en skræmmende opgave, hvis administratoren ikke er bekendt med formålene med hvert af lagringsaspekterne.

Den første betegnelse er kendt som 'SR' eller Storage Repository. Dette er uden tvivl det vigtigste udtryk i XenServer-lagring, da det repræsenterer det fysiske medium, som virtuelle maskindiske vil blive gemt og hentet til. Lagringsopbevaringssteder kan være en hvilken som helst af flere forskellige typer opbevaringssystemer, herunder lokal opbevaring knyttet fysisk til XenServer-værten, iSCSI/Fibre Channel LUN, NFS Network File Shares eller opbevaring på et Dell/NetApp-opbevaringsapparat.

Lageropbevaringssteder kan deles eller dedikeres og kan understøtte adskillige nyttige funktioner såsom hurtig kloning, sparsom allokering (lager til rådighed som den virtuelle maskine har brug for det) og re-størrelse virtuelle diskbilleder (mere om disse senere).

Lageropbevaringssteder, SR, er logisk forbundet med en XenServer-vært med det, der er kendt som en fysisk blokeringsenhed, mere almindeligt omtalt som 'PBD'. PBD er simpelthen en henvisning til et lagersted. Disse PBD-objekter kan "tilsluttes" til en XenServer-vært for at give denne vært mulighed for at læse/skrive information til det lagringslager.

Formålet med Storage repositories er primært at gemme de virtuelle maskine Virtual Disk Image (VDI) filer. VDI-filer er pletter på en SR, der er tildelt til at indeholde operativsystem og andre filer til virtuel maskine, der kører på XenServer-værten. VDI-filer kan være af flere forskellige typer. Typen bestemmes af typen lageropbevaring.

Almindelige VDI-typer i XenServer er Logical Volumes (LV), der administreres af Logical Volume Manager, Virtual Hard Disk (VHD), eller de kan være Logical Unit Numbers (LUN) på en Dell- eller NetApp-lagerenhed. Bemærk: Denne artikel bruger LUN'er på en Dell-lagerenhed.

Disse VDI-filer er logisk forbundet til virtuelle maskiner via et objekt kendt som en Virtual Block Device, der almindeligvis kaldes 'VBD'. Disse VBD-objekter kan knyttes til virtuelle gæster, som derefter giver gæstemaskinen adgang til de data, der er gemt i den bestemte VDI på en respektive SR.

Ligesom netværk i XenServer er læsning om opbevaring en ting, men at være i stand til at se forholdet mellem hver af disse ting styrker ofte begreberne. De almindelige diagrammer, der bruges til at repræsentere XenServer-opbevaringskoncepter, forveksler ofte nyere mennesker, da diagrammerne ofte læses lineært. Nedenfor er et sådant billede lånt fra Citrix.

Mange individer læser dette lineært fra venstre mod højre og tænker at hver del er en separat fysisk enhed. Dette er ikke tilfældet og fører ofte til meget forvirring om, hvordan XenServer-opbevaring fungerer. Grafikken nedenfor forsøger at forklare begreberne på en mindre lineær, men mere pragmatisk måde.

Forhåbentlig forvirrer ovenstående grafik ikke enkeltpersoner yderligere omkring XenServer-opbevaring. Det andet billede er et forsøg på at vise de logiske forbindelser (PBD og VBD), der bruges til at forbinde XenServers og gæster til fjernlager via en faktisk netværksforbindelse.

Med begrebet ude af vejen; konfigurationen kan begynde. På baggrund af den første artikel i denne serie bruger denne vejledning en Dell PS5500E iSCSI-lagerenhed til opbevaring af virtuelle maskindiske (gæster). Denne vejledning gennemgår ikke konfigurationen af Dell iSCSI-enheden.

  1. XenServer 6.5 installeret og patched (del 1 af serien)
  2. Dell PS5500E iSCSI-enhed (andre iSCSI-enheder kan bare bruges til at erstatte miljøoplysninger, hvor det er nødvendigt).
  3. XenServer-netværksgrænseflader er konfigureret (del 3 i serien).
  4. iSCSI-enhed og XenServer kan logisk set se hinanden (via ping-værktøj).
  5. CIFS (SAMBA) -server, der kører og hoster en del af CD ISO-filer (ikke påkrævet, men meget nyttigt).

Oprettelse af Citrix XenServer Storage Repository

Denne første proces gennemgår trinene til oprettelse af en software iSCSI-initiator fra XenServer-værten til Dell PS5500E.

Denne særlige LUN bruger Challenge-Handshake Authentication Protocol (CHAP) til at begrænse adgangen til iSCSI-volumen til visse autoriserede parter.

For at oprette lagringsregisteret vil en traditionel 'xe' kommando forekomme. De korrekte iSCSI-oplysninger skal opnås inden oprettelse af lagerlageret.

Ved at videregive parameteren 'sr-probe' til 'xe' -værktøjet instrueres XenServer i at forespørge en lagerenhed til iSCSI IQN (iSCSI Qualified Name).

Den første kommando ser først intens ud, men den er ikke så dårlig, som den ser ud.

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

Denne første kommando er nødvendig for at samle SCSI IQN til konfiguration af lagerlager. Før vi går videre, skal vi se på alle dele af denne kommando.

  1. sr-probe - Bruges til at forespørge iSCSI-enheden for at få oplysninger om den volumen, der er oprettet for denne XenServer-vært.
  2. type = Bruges til at fortælle XenServer lagringslagertypen. Dette vil variere afhængigt af hvilket system der bruges. På grund af brugen af Dell PS5500 bruges lvm over iSCSI i denne kommando. Sørg for at ændre, så den passer til lagerenhedstypen.
  3. device-config: target = Bruges til at fortælle XenServer, hvilken iSCSI-enhed der skal søges efter IP-adresse.
  4. device-config: chapuser = Dette bruges til at godkende til iSCSI-enheden. I dette eksempel er en iSCSI-volumen oprettet tidligere for brugeren "tecmint". Ved at sende brugernavnet og adgangskoden i denne kommando, reagerer iSCSI-enheden tilbage med de nødvendige oplysninger for at afslutte oprettelsen af lageropbevaringsstedet.
  5. device-config: chappassword = Dette er adgangskoden til ovenstående CHAP-brugernavn.

Når kommandoen er indtastet og indsendt, vil XenServer forsøge at logge ind på iSCSI-enheden og returnere de nødvendige oplysninger for faktisk at tilføje denne iSCSI-enhed som et lagerlager.

Nedenfor er, hvad testsystemet returnerede fra denne kommando.

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>

Det fremhævede stykke her er kendt som iSCSI IQN. Dette er meget vigtigt og er nødvendigt for at bestemme SCSIid til lageret. Med denne nye information kan den forudgående kommando ændres for at 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, der føjes til kommandoen, er targetIQN-strofe. Ved at udstede denne nye kommando vil systemet svare med det sidste stykke information, der er nødvendigt for at oprette et iSCSI Storage Repository. Det sidste stykke information er SCSI-id'et.

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 punkt er alle de nødvendige stykker til at oprette et iSCSI Storage Repository tilgængelige, og det er på tide at udstede kommandoen for at tilføje denne SR til denne særlige XenServer. Oprettelse af lagerlageret fra de kombinerede oplysninger gø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 godt, opretter systemet forbindelse til iSCSI-enheden og returnerer derefter UUID'et for det nyligt tilføjede Storage Repository.

bea6caa4-ecab-8509-33a4-2cda2599fb75

UUID-output er et godt tegn! Som med alle systemadministrationsopgaver er det altid en god ide at bekræfte, at kommandoen var vellykket. Dette kan opnås med en anden 'xe' kommando.

# xe sr-list name-label="Tecmint iSCSI Storage"
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-output har denne XenServer oprettet forbindelse til Dell iSCSI-enheden og er klar til at gemme gæstevDI-filer.

Oprettelse af ISO-lagringsregister

Den næste række trin gennemgår processen med at oprette et ISO-bibliotek. ISO-filer er typisk billeder af CD-installationsmedier.

Ved at få oprettet et specielt lageropbevaringssted til disse ISO-filer kan installationen af nye gæster udføres meget hurtigt. Når en administrator ønsker at oprette en ny gæst, kan de simpelthen vælge en af de ISO-filer, der findes i dette ISO-bibliotek, i stedet for at skulle lægge en CD fysisk i en XenServer i puljen.

Denne del af guiden antager, at brugeren har en fungerende SAMBA-server. Hvis en SAMBA-server ikke er konfigureret, er du velkommen til at læse denne artikel om, hvordan du udfører denne opgave i Red Hat/Fedora (jeg vil have en Debian SAMBA-servervejledning i fremtiden):

  1. Opsæt Samba Server til fildeling

Det første trin er at indsamle de nødvendige legitimationsoplysninger og konfigurationsoplysninger til SAMBA ISO-biblioteket. Når brugernavnet, adgangskoden og forbindelsesoplysninger er tilgængelige, kan en simpel 'xe' kommandovariant bruges til at forbinde SAMBA-biblioteket til XenServer.

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

Denne kommando udsender ikke noget til skærmen, medmindre den fejler. For at bekræfte, at den faktisk monterede SAMBA ISO-delingen, skal du udstede en anden 'xe' kommando:

# xe sr-list
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-vært er nu konfigureret med både et iSCSI Storage Repository samt et CIFS ISO-bibliotek til at gemme installationsmedier til virtuelle maskiner (gæster).

De næste trin vil være oprettelsen af virtuelle maskiner og tilslutning af disse systemer til de rette netværk fra den tidligere netværksartikel.