107
szerkesztés
Módosítások
a
A „Project” menüpont alatt található „Network” lehetőséget választva láthatók a hálózattal kapcsolatos lehetőségeink. A Segédlet L3 (SMART) hálózat létrehozásához első lépésként a „Networks” lehetőséget kell választanunk, ahol láthatók a már korábban létrehozott hálózatok, valamint itt érhetők el a Flat típusú hálózatok is, amennyiben egy admin jogosultságú felhasználó megosztott, vagy a projekthez rendelt egy ilyen típusú hálózatot. Új hálózat létrehozásához a jobb felső sarokban válasszuk a „Create Network” lehetőséget, majd a következő képeken látható módon töltsük ki a szükséges mezőket.az alábbi oldalon tekinthető meg:
Debian:Ubuntu 18.04 (ajánlott)
echo "deb http://http.debian.net/debian jessieadd-backports main" >>/etc/apt/sources.list.d/openstack.list-repository cloud-archive:rocky
Ubuntu (A 16.04-es verziótól Mitaka verziót tölt le az eredeti konfigurációval)Debian Buster:
→C4E (Openstack) Publikus API
A táblázatban látható root lemezek mérete természetesen a virtuális gép létrehozásakor változtatható.
===Régiók - Zónák===
A C4E nemrég véghezvitt bővítései miatt a felhasználóknak lehetőségük van földrajzilag elosztani (Régiók) és géptermen belül izolálni (Zónák) az igényelt erőforrásokat.
Jelenleg két régiónk van: "RegionOne" és "RegionTwo".
Mindkét fenti régióban elérhető 2-2 zóna: "Zone1" és "Zone2"
===Felhasználói felület bemutatása===
Az általunk megépített rendszerben végül két fajta hálózat kapott helyet:
* Az egyik típus, amit Flat néven kereszteltünk el. Ennek lényege, hogy a létrehozott virtuális gépek egy előre meghatározott publikus IP tartományból DHCP segítségével felvesznek egy címet, majd a csomagok haladásának iránya közvetlenül a compute gépek felé történik, ezzel nem terhelve a network gépeket.
** <small>A FLAT1 '''Flat1''' névre keresztelt hálózathoz tartozó szabad IPv4 címek száma '''nagyon kevés''', ezért kérjük a felhasználóinkat, hogy lehetőség szerint, amennyiben FLAT típusú hálózatot szeretnének hozzáadni az újonnan létrehozott virtuális gépekhez, a FLAT2 '''Flat2 és Flat3''' nevű hálózatot válasszák. Megértésüket és együttműködésüket köszönjük!</small>
* A másik hálózati típus, amely az Smart nevet kapta. Ez a hálózati típus nagyban különbözik az előző megoldástól, mivel ennél a típusnál a felhasználóknak lehetőségük van egy, vagy akár több privát hálózat, valamint egy vagy több ezekhez tartozó virtuális router létrehozására. A virtuális router-hez lehetőség van hozzárendelni IP címeket a privát, valamint egy publikus hálózatból is és ennek következtében a virtuális gépek forgalmában egy úgynevezett hálózati címfordítás történik. Ennek előnye az előző megoldással szemben, hogy kevésbé IP cím pazarló a publikus címek tekintetében, valamint a neutron funkciójának köszönhetően képes több network gép között tartalékolt lenni.
====External (L3) hálózat létrehozása====
[[File:Create_network1.png|727px|hálózat létrehozása]] [[File:Create_network2.png|723px|hálózat létrehozása]] A fentebb látható menüben az átjáró IP címét nem kötelező megadni, ilyenkor automatikusan a megadott tartomány első IP címét fogja átjárónak beállítani. Ebben az esetben 192.168.66.1 címet. [[File:Create_network3.png|723pxCloud for Education/network l3|L3 hálózat létrehozása]] Ha minden szükséges és kötelező mezőt kitöltöttünk, akkor a „create” gombra kattintva a rendszer létrehozza a hálózatot a kívánt paramétereinkkel, amelyet a Networks menüpont alatt megtekinthetünk.
====Router létrehozása és Interfészek hozzáadása====
====LBaaS====
A C4E az "OpenStack Octavia" alapú LoadBalancer-t kínálja a felhasználóknak, HAProxy backenddel.Az esetleges titkosított kapcsolatok terminálásakor a "Barbican" tanúsítvány manager eszköz biztosítja a privát kulcsok biztonságos tárolását. A terheléselosztó konfigurációs beállításai két fajta módon tehető meg: 1. Horizon grafikus felületen a NETWORK menüpont alatt, 2. CLI használatával, amelyhez a standard OpenStack CLI eszközön felül az alábbi csomagok telepítése is szükséges. (Debian/Ubuntu rendszeren)<pre>$ apt install python-barbicanclient python3-octaviaclient</pre> [[Cloud for Education#C4E_.28Openstack.29_Publikus_API|Általános CLI használati információk]] '''Rövid ismertető:''' [[File: Octavia-component-overview.jpg |724px|Octavia component overview]] Az Octavia LBaaS rendszer az alábbi főbb komponensekből áll:* Amphorae: Különálló virtuális gépek, amik egy Ubuntu alapú Amphora image-ből példányosodnak, mikor a felhasználó új terheléselosztót hoz létre** A sablon image-ből létrehozott virtuális gépek nem számítanak bele a felhasználói kvótába, azok flavor-je specifikus, belépni rájuk a felhasználó nem tud* Octavia&Barbican API* Controller Worker (az API kérések alapján vezérli a háttérkomponenseket)* Health Manager (figyeli a már létrehozott "Amphorae" virtuális gépeket, és azok állapotát, hiba esetén failover műveleteket hajt végre)* Housekeeping Manager (a hibás/törölt maradványok eltávolításáért felel)* Driver Agent (információkat fogad az egyes amphora példányokon futó Haproxy drivertől) A fentiek közül a felhasználónak csupán az API-val kell kommunikálnia, akár a Horizon felületén, akár a CLI-ből szeretné létrehozni és managelni a LoadBalancer-t. '''Segédlet a létrehozáshoz példákkal illusztrálva:'''* Példa [[Cloud for Education/LBaaS funkció jelenleg gui|GUI]] igénybevételével* Példa [[Cloud for Education/LBaaS cli|CLI]] használatával '''Működés/Hibatűrés:''' A rendszer alapvető elosztottsága miatt nincs központi "leállás", minden egyes terheléselosztó pont annyira stabil, mint a C4E-ben futó többi virtuális gép. Alapvetően egy adott projekt egy adott terheléselosztójához tartozó amphora image hibája (virtuális gép leáll, lefagy) esetén a Health Managerre hagyatkozunk. A gép újraindításán túl akár egy '''új amphorae virtuális gép'''et is létre tud hozni a háttérben, és a már '''meglévő konfiguráció'''t alkalmazni rá.Arra azonban figyelni kell, hogy egy újraindítás, vagy egy új image létrehozása néhány perces kiesést jelenthet az adott projekthez tartozó terheléselosztó szolgáltatásban, de ilyenre alapvetően nem számítunk. Fontos, hogy egy korábbi tervezett leállításkor (ahol kézzel többször leállítottuk a már meglévő terheléselosztókat) a Health Manager sajnálatos módon nem tudta a többszöri leállítást és újraindítást (egymásra futva) megfelelően kezelni. Itt a karbantartás végén adminisztrátori beavatkozásra volt szükség, kézzel kellett failovert kérni minden terheléselosztóra.Erre a forgatókönyvre se számítunk üzemszerű használat mellett (maximum egy esetleges tervezett leálláskor, nem várt komolyabb hiba javításakor) de erre minden esetben nagy figyelmet fordítanak a karbantartást/javítást végző kollégák. '''Amennyiben beragadt/hibás terheléselosztót észlelnek, kérjük forduljanak ügyfélszolgálatunkhoz!''' '''Terheléselosztó törlése:''' Sajnálatos módon előfordulhat, hogy egy-egy terheléselosztó nem elérhetőtörölhető és hibaüzenet figyelmeztet erre.('''CLI-n van rá force opció!''') Ennek a megoldása, hogy "szét kell szedni" a terheléselosztót, amelyhez a következő lépésekre van szükség:* törölni kell a pool-t, a listener-t, a monitort* majd végül magát a terheléselosztót
====FWaaS====
Az FWaaS funkció jelenleg nem elérhető.
===Lemez típusok===
{| class="wikitable" border="1"
|-
| Lemez típus
| Sebesség
| Méret
| Technológia
| Javasolt használat
|-
| SDS-Nearline
| +
| +++
| Skálázódó szoftveres tároló
| Tömeges adattárolás, alacsony kihasználtságú VM lemeze.
|-
| SDS-SAS
| ++
| ++
| Skálázódó szoftveres tároló
| Általános célú adattárolás, változó adatok, normál kihasználtságú VM lemeze.
|-
| SAN-Nearline
| +
| +++
| Klasszikus SAN storage
| Tömeges adattárolás, alacsony kihasználtságú VM lemeze.
|-
| SAN-SAS
| ++
| ++
| Klasszikus SAN storage
| Általános célú adattárolás, változó adatok, normál kihasználtságú VM lemeze.
|-
| SAN-SSD
| +++
| +
| Klasszikus SAN storage
| Gyakran változó adatok, magas kihasználtságú VM lemeze.
|-
|}
==Virtuális gép indítása==
A folyamat elvégzése után elkészült az első virtuális gép, amelynek elérése több féle módon történhet.
* A virtuális géphez hozzárendelünk egy publikus IP címet, majd a virtuális router segítségével háttérben a neutron 1:1 NAT alkalmazásával ennek megfelelően konfigurálja a virtuális routert, és így távolról is bejelentkezhetünk rá, Linux disztribúció esetén például SSH, Windows esetén RDP szolgáltatás segítségével.
* A weboldalba ágyazott VNC konzol segítségével vezérelhetjük gépünket, azonban egyes előre gyártott lemezképfájlból készített virtuális gépek nem támogatják csak a kulcsos autentikációt, így sajnos ezeknél a gépeknél ez a módszer nem elérhető.
Az előzőekben létrehozott Ubuntu operációs rendszerrel ellátott virtuális gépünk a második lehetőséget nem támogatja, így szükségünk van a gép eléréséhez egy publikus IP címre, amelynek allokálása és géphez rendelése a következőképpen történik.
Első lépésben válasszuk a „Compute” „Project” alatt található „Access & Security” „Network” lehetőséget, majd azon belül a „Floating IPs” menüpontot és kattintsunk a jobb felső sarokban lévő „Allocate IP To Project” gombra. A megjelenő ablakban ki kell választani a kívánt Smart hálózatot, amelyből a publikus IP címet szeretnénk használni (Ez nyilván az a hálózat, amelyiket a router átjárójának is választottunk), majd az „Allocate IP” lehetőséget kell választani.
[[File:Allocate1Allocate_ip1.png|726px|Floating IP igénylése]]
A következő ábrán látható a Projekthez allokált IP címek listája, amelyek következő lépésként hozzárendelhetők 1-1 virtuális géphez. Ehhez válasszuk az ábrán látható IP cím mellett található „Associate” lehetőséget, majd válasszuk ki a listából azt a virtuális gépet, amelyiken az IP címet használni szeretnénk.
[[File:Allocate2Allocate_ip2.png|726px|Rendelkezésre álló IP címek listája]]
[[File:Allocate3Allocate_ip3.png|726px|Floating IP géphez rendelése]]
A sikeres hozzárendelés után a gépünk már rendelkezik publikus IP címmel, amelyen keresztül külső hálózatokból is elérhetjük a gépet, amennyiben ezt a Security Group-ban, vagy a Firewall alatt engedélyezzük.
# Igennel kell válaszolni, hogy automatikusan elinduljon az iSCSI a továbbiakban
# A megnyitott ablakban a "Konfiguráció" fül alatt a "Kezdeményező neve:" részhez be kell állítani az IQN-t, amit a storage igénylésekor megadtunk (ehhez az alatta lévő módosítás gombra kell kattintani)
===Virtuális gépek migrálása Régiók között===
A migráláshoz CLI elérés, és elegendő tárhely szükséges! A jobb teljesítmény érdekében a migrálást végző gép akár a felhőben is futtatható, így nem limitál az otthoni sávszélesség.
# A virtuális gépről először snapshot-ot kell készíteni
# Az elkészült snapshot-ból újra létre kell hozni egy volume-ot (virtuális gép nélkül)
# A létrejött új volume-nál megjenik egy opció: Upload to Image (ez a diszk méretétől hosszú ideig is eltarthat!)
# A létrejött image innentől letölthető a CLI-n keresztül:<pre> glance image-download --file $FILENAME $UUID</pre>
# A letöltött file-t például így kell feltölteni: <pre>openstack image create --min-disk 5 --disk-format raw --container-format bare --file /tmp/valami.raw --property murano_image_info='{"title": "Migralt virtualis gep", "type": "linux"}' NewVM </pre>
== C4E (Openstack) Publikus API ==
Amennyiben az IP valóban hazai cím, és még nem szerepel a tűzfalban, rövid távon permanensen az egész alhálózat számára elérhetővé tesszük az API-t.
<big> '''FONTOS!''' </big> Minden itt leírt dokumentáció a C4E openstack jelenlegi (MitakaRocky) verziójához készült!
Kialakításra került a C4E publikus API elérése. Ahhoz, hogy a felhasználók ezt igénybe tudják venni, az alábbiak szükségesek:
* Első lépésben küldeni Meg kell egy levelet az alábbiakkal nyitni a '''cloud@: https://keystone.c4e.niif.hu''' címre:/regsite/apipwgen oldalt.** C4E projekt(ek) neveÚj jelszó beállítását kérni.** C4E usernév (ez szinte biztosan az eppn)A kapott jelszót felírni.** Privát kezelésben lévő belföldi mobiltelefon száma, ahova SMS formájában küldjük el az eléréshez szükséges Ajánlott a kapott jelszót A levélnek arról az e-mail címről kell származnia, ami az adott intézmény IdP-je adott át utólag a C4Ewebfelületen (vagy CLI-nek az eppn mellettből) módosítani!
=== Kezdő lépések: környezet kialakítása (Debian/Ubuntu) ===
Első körben hozzá kell adni a repository-t az apt konfigurációjához, frissíteni a csomaglistát, majd telepíteni a szükséges csomagokat:
<pre>
apt-get update
apt-get install python-openstackclient
</pre>
<pre>
curl http://osbpo.debian.net/osbpo/dists/pubkey.gpg | sudo apt-key add -
echo "deb http://osbpo.debian.net/osbpo buster-rocky-backports main" >>/etc/apt/sources.list.d/openstack.list
echo "deb http://osbpo.debian.net/osbpo buster-rocky-backports-nochange main" >>/etc/apt/sources.list.d/openstack.list
apt-get update
apt-get install python-openstackclient
* Az <big>''' Access & Security -> API Access '''</big> oldalon a <big>''' Download OpenStack RC File v3 '''</big> opciót választani
* Az rc file-t a kezelő gépre juttatni (ha nem ott lenne)
* <big>Fel kell venni</big> az rc file-ba az alábbi sort: '''export OS_VOLUME_API_VERSION=3'''
* Az rc file-ban specifikálni <big>kell</big> a régiót, pl.: '''export OS_REGION_NAME="RegionTwo"''' (vagy RegionOne)
A harmadik lépés, hogy betöltjük az rc file-t, majd a jelszó beírása után elérhetővé válik a C4E API
