Nebula pilvi 9.0 saatavuusalueiden välinen verkkoliikenne

Nebula pilvi 9.0 saatavuusalueiden välinen verkkoliikenne

Sivu 2/9 1. Sisällysluettelo 2. Esipuhe 3 2.1. Saatavuusalueet 3 2.1.1. Taustaverkko missä instanssit ovat suoraan fyysisellä liitännällä kiinni 3 2.1.2. Liikenne kulkee reititettynä taustaverkon kautta 6 3. Yhteenveto 9

Sivu 3/9 2. Esipuhe Dokumentissa kuvataan muutama vaihtoehto millä Nebulan Openstack pilvessä voidaan liikennöidä saatavuusaluiden välillä parhaiden käytäntöjen mukaisesti. Dokumentti on tarkoitus julkaista asiakasohjeissa. Ohjeessa on myös useampi heat template asian havainnoimiseksi. 2.1. Saatavuusalueet Nebula Pilvi 9.0 sisältää kaksi saatavuusaluetta joihin asiakas voi itsenäisesti hajauttaa palvelut korkean saatavuuden takaamiseksi. Hajautus vaatii kuitenkin hieman suunnittelua verkon ja palvelimien roolien osalta, jotta haluttuun ratkaisuun päästään. Tässä ohjeessa näytetään muutama esimerkki yksikertaisen sovelluksen kautta millä tavoin palvelut voivat liikennöidä saatavuusaluiden välillä tehokkaasti ja turvallisesti. 2.1.1. Taustaverkko missä instanssit ovat suoraan fyysisellä liitännällä kiinni Esimerkissä luomme molemmille saatavuusalueille demilitarisoidut verkot jonka kautta instanssit voivat liikennöidä internettiin sekä käyttää julkisia ip-osoitteita. Luomme myös yhden taustaverkon josta ei ole suoraa yhteyttä internettiin, mutta instanssit voivat liikennöidä sen kautta keskenään. Verkkojen ja instanssien luomiseen käytetään esimerkissä heat templateja joilla voidaan automatisoida ja versioida kyseiset infrastruktuurit. Luotavat verkot ovat kuvattuna alla olevassa taulukossa: Saatavuusalue Verkko CIDR Rooli Reititin Helsinki-1 Helsinki-2 Useita dmz-hki1-10.0.1.0/24 dmz-hki2-10.0.10.0/24 multiaz-lan- 192.168.0.0/24 10.0.1.0/24 DMZ edge_router_hki1 10.0.10.0/24 DMZ edge_router_hki2 192.168.0.0/24 Taustaverkko - Huomioitavaa on se että instanssit voi myös liittää ristiin DMZ verkkoihin saatavuusalueiden välillä. Tätä ei ole Nebulan pilvessä estetty, mutta loogisuuden kannalta ei ole suositeltua käyttää verkkoja ristiin. Mikäli verkkoon liitetään reititin ja sen yhdyskäytävä määritetään esimerkiksi saatavuusalueelle helsinki-1 niin verkkoliikenne ulos pilvestä kulkee helsinki-1 kautta. Instanssi joka sijaitsee saatavuusalueella helsinki-2 voi käyttää verkkoa, mutta mikäli saatavuusalueella helsinki-1 on vikatilanne tai huoltokatko niin instanssien liikenne internettiin katkeaa. Tämän vuoksi paras käytäntö on luoda erilliset verkot internettiin päin suuntautuvaa liikennettä varten kyseiselle saatavuusalueelle mikäli tälle on tarvetta ja eriyttää saatavuusalueiden välinen liikenne omiin verkkoihin.

Sivu 4/9 Vaikka alla oleva topologia on mahdollinen, se ei ole suositeltu tapa liittää instanssi julkiseen verkkoon: Luomme aluksi stackin, jossa määritetään verkot sekä security-group palomuurisäännöt: $ heat stack-create -f multiaz_net.yaml demo-network-multiaz fcda2042-b3b4-4d88-b485-590dd199081c demo-network-multiaz CREATE_IN_PROGRESS 2015-09-10T08:12:41Z

Sivu 5/9 Valmiin stackin verkkotopologia: Molemmilla saatavuusalueilla on erilliset DMZ verkot internetiin liikennöintiä varten ja taustaverkko johon ei ole liityntää yhdeltäkään reitittimeltä. Seuraavaksi luodaan stackki joka provisioi 2 instanssia. Toinen on frontend palvelin saatavuusaluella helsinki-1 ja toinen tietokantapalvelin saatavuusalueella helsinki-2. Huomaa että kyseinen skenaario on vain havainoillistamista varten. Oikeasti kyseinen ratkaisu ei olisi vikasietoinen koska molemmat palvelimet ovat riippuvaisia toisistaan. Huom: muuta tiedostosta parametri key_name -> default: demokey nimi vastaamaan omaa avaintasi. $ heat stack-create -f servers_with_multiaz_net.yaml wp-servers-net fcda2042-b3b4-4d88-b485-590dd199081c demo-network-multiaz CREATE_COMPLETE 2015-09-10T08:12:41Z eef11217-3268-4767-8c95-6462ad7ce981 wp-servers-net CREATE_IN_PROGRESS 2015-09-10T08:21:10Z

Sivu 6/9 Instanssit ovat luotuna eri saatavuusalueille ja ne liikennöivät keskenään taustaverkossa saatavuusalueiden välillä: Wordpress asennus tulee viimeistellä selaimella. Osoitteen voi tarkistaa suoraan valmiista stackista: $ heat output-show wp-servers-net website_url http://77.86.182.201/wordpress/ Lopuksi stackin voi tuhota komennolla: $ heat stack-delete wp-servers-net 2.1.2. Liikenne kulkee reititettynä taustaverkon kautta Vaihtoehtoisessa tavassa olemassa olevat reitittimet hoitavat reitityksen verkkojen välillä käyttäen saatavuusalueiden välillä olevaa taustaverkkoa. Mallia kannattaa käyttää silloin kun verkkotopologia on iso ja segmentoituja verkkoja on useita jotka eivät ole suoraan yhteydessä internettiin ja liikenteen tulee toimia kyseisten verkkojen välillä. Myös sisäisiä reitittimiä voi käyttää ilman liitosta internettiin. Päivitämme jo luodun stackin malliin missä reitittimiin liitetään portit saatavuusalueiden väliseen verkkoon: $ heat stack-update -f multiaz_net_routers.yaml demo-network-multiaz fcda2042-b3b4-4d88-b485-590dd199081c demo-network-multiaz UPDATE_IN_PROGRESS 2015-09-10T08:12:41Z

Sivu 7/9 Päivityksen jälkeen reitittimillä on linkit taustaverkkoon. Heat ei vielä suoraan tue staattisten reittien lisäämistä reitittimille joten toimenpide joudutaan tekemään neutronin omalla cli-työkalulla. Reitit DMZ verkkojen välillä reititetään ristiin taustaverkon kautta: $ neutron router-update edge-router-hki1 --routes type=dict list=true destination=10.0.10.0/24,nexthop=192.168.52 Updated router: edge-router-hki1 $ neutron router-update edge-router-hki2 --routes type=dict list=true destination=10.0.1.0/24,nexthop=192.168.53 Updated router: edge-router-hki2 Huom: kun reititin halutaan tuhota, staattiset reitit tulee poistaa ennen toimenpidettä: $ neutron router-update edge-router-hki1 --routes action=clear Voimme nyt luoda stackin, jossa instanssit ovat kiinni vain omissa DMZ verkoissaan, mutta ne voivat liikennöidä keskenään reitittimien kautta: $ heat stack-create -f servers_with_multiaz_net_routed.yaml wp-servers-routed fcda2042-b3b4-4d88-b485-590dd199081c demo-network-multiaz UPDATE_COMPLETE 2015-09-10T08:12:41Z 461ad670-139d-4c4d-b95b-1ce451678ef1 wp-servers-routed CREATE_IN_PROGRESS 2015-09-10T09:24:48Z

Sivu 8/9 Instanssit ovat omissa verkoissaan eri saatavuusalueilla ja liikenne kulkee taustaverkkoa pitkin reititettynä: Wordpress asennus tulee taas viimeistellä selaimen kautta: $ heat output-show wp-servers-routed website_url http://77.86.182.202/wordpress/ Stackit voi lopuksi tuhota järjestyksessä: $ heat stack-delete wp-servers-routed fcda2042-b3b4-4d88-b485-590dd199081c demo-network-multiaz UPDATE_COMPLETE 2015-09-10T08:12:41Z 461ad670-139d-4c4d-b95b-1ce451678ef1 wp-servers-routed DELETE_IN_PROGRESS 2015-09-10T09:24:48Z $ neutron router-update edge-router-hki1 --routes action=clear Updated router: edge-router-hki1 $ neutron router-update edge-router-hki2 --routes action=clear Updated router: edge-router-hki2 $ heat stack-delete demo-network-multiaz fcda2042-b3b4-4d88-b485-590dd199081c demo-network-multiaz DELETE_IN_PROGRESS 2015-09-10T08:12:41Z

Sivu 9/9 3. Yhteenveto Esimerkissä käytiin läpi kaksi tapaa liikennöidä saatavuusaluiden välillä. Muitakin vaihtoehtoja on, mutta esitetyt mallit olivat suositeltavat tavat miten Nebula Pilvi 9.0 liikenne kannattaa toteuttaa. Huomioon otettavia asioita kun verkkoja suunnitellaan: Pidä instanssit ja niiden verkot samalla saatavuusalueella. Älä liikennöi internettiin tai käytä floating-osoitteita ristiin saatavuusalueiden välillä. Mikäli instanssi ei tarvitse julkista floating-osoitetta niin älä käytä niitä turhaan. Tietokanta tai applikaatiopalvelimen ei välttämättä tarvitse näkyä internettiin suoraan. Suunnittele verkot kokonaisuuksina. Mikäli pilvessä pyörivä palvelu on tarkoitus myöhemmin yhdistää toiseen verkkoon tai palveluun niin vältä avaruuksien päällekkäisyyksiä. Hyvä käytäntö on pitää pilvessä esim. 172.16.0.0/12 verkkoja tai toimipisteissä 10.0.0.0/8 tai toisinpäin. Tee aina security-group säännöt palvelukohtaisesti, vältä kaikki auki ratkaisuja vaikka verkot eivät suoraan olisikaan yhteydessä julkisiin verkkoihin. Instansseja voi segmentoida verkkoihin joista ei ole suoraa pääsyä internettiin. Mikäli näiden palvelimien on tarkoitus päästä ajamaan esimerkiksi tietoturvapäivitykset niin käytä NATinstansseja. Mikäli käytät heat-templateja, tee jokaiselle toiminnolle oma template ja viittaa niihin keskenään. Esimerkiksi verkot omanaan, tietokanta ja applikaatiopalvelimet ominaan jne. Näin muutokset voi tehdä tiettyyn osaalueeseen kerrallaan. Lisäkysymyksissä tai kommenteissa voitte olla yhteydessä meihin. Avustamme mielellämme!