VMware-ről OpenStack-re vált a Paypal és az eBay

Open Source

A VMware valószínűleg nem örül annak a hírnek, miszerint a Paypal és a eBay lerántja körübelül 80 ezer szerveréről szoftvereit és helyette szabad, nyílt forrású OpenStack-et fog munkára. A hír forrása Boris Renski, az OpenStack Foundation vezetőségi tagja.

Első körben a Paypal kb. 10 ezer szervert állít át VMware-ről. Ezek a szerverek még a nyár folyamán éles üzembe mennek. A részletek itt olvashatók.

( trey | 2013. 03. 26., k – 10:55 )

Tippeket: Red Hat vagy Ubuntu vagy valami más?

--
trey @ gépház

Mi a konkrét kérdésed?

A VMware-nek van egy csomó terméke. vSphere, vCloud stb. Valamelyikről váltanak. Gyanítom, hogy vCloud-ról.

Az OpenStack egy IaaS - mint a vCloud - aminek legtöbbször Linux az alapja. Mivel a Red Hat és az Ubuntu tolja ilyen szinten komolyan az OpenStack-et, tippelem, hogy valamelyik céggel fognak közelebbi viszonyba kerülni.

Fyodor és az nmap hogy jön ide?

--
trey @ gépház

Szerintem az egy kényszeredett lépés volt. Nem gondolnék mögé semmi komolyat. Legalábbis addig, amíg valami konkrét termékbejelentés nem érkezik a VMware-től.

The Morning Download: VMware Punts on OpenStack
VMWare Is Right: Not Every Cloud Needs OpenStack

--
trey @ gépház

A linkelt cikk (HUP szabály, hogy mindig el kell olvasni) egyértelműen fogalmaz:

PayPal and eBay are yanking VMware software from some 80,000 servers and replacing it with the free and open-source alternative known as OpenStack, Boris Renski, OpenStack Foundation board member told Business Insider.

A "replacing" szót nem lehet félreérteni.

--
trey @ gépház

Annyiban igaza lehet, hogy a VMWare software jelentheti csak a vCloud-ot is, de a virtualizációs réteg marad VMWare. Vagy ESXi, saját supporttal :)
Viszont, ha tippelnék, akkor én is inkább azt mondanám, hogy Ubuntu, vagy Debian, és Xen-nel. A Xen-t többen kiforrottabnak tartják erre nagyobb cégeknél, bár szerintem a tapasztalat nagysága nagyobb, és a régi disk I/O (nem)teljesítménye a KVM-nek.
Viszont, ha arra gondolok, hogy mi a legösszeboronáltabb lehetőség, akkor Ubuntu + KVM + openstack, egyedi szkriptekkel.

Értettem én is, hogy mire gondol. A cikket elolvasva - aminek a címe az hogy "In A Dangerous Sign For VMware, PayPal Chooses Rival OpenStack" -, nekem az jött le, hogy dobnák teljesen a VMware cuccait.

Azután pedig, hogy a HP a publikus cloud-ja alá Ubuntu / OpenStack-et tett, semmi okát nem látom, hogy miért ne lehetne mondjuk Ubuntu / KVM / OpenStack a választásuk. Főleg, hogy a Canonical elég jól nyomja.

--
trey @ gépház

A CapGiminis arcok pl az Ubuntu+Xen+OpenStack cuccra esküsznek, és egy majd 10.000 fős "vékony"* kliensgépes környezetet üzemeltetnek rajta. *vékony: mikor a user bebootol, akkor kap egy környezetet rögtön, imageból kicsomagolva, ami az openstackes környezetben lévő rendszerre jelentkezik be, és ott van a munkakörnyezete, logoffnál, pedig egy wipe van a gépen.

Azon gondolkodtam, hogy ha az Ubuntu / KVM / OpenStack vonal mellett döntenének, akkor nem egy járatlan utat kellene kitaposniuk, hiszen a HP pl. ezt a stacket betette a publikus cloud-ja alá. Ráadásul a Dell neve is említésre került a cikkben. A Dell és a Canonical elég szoros együttműködésben vannak.

--
trey @ gépház

Ez így van, viszont én nem hiszek olyanban, hogy ekkora cégeknél meglépik azt, hogy egy homogén, full VMware környezetről letépik a fele VMware-t, majd a maradékra rátesznek egy nyílt forrású megoldást. Több dolog is szól ez ellen szerintem:

- miért rúgnák össze a port a VMware-rel?
- ha csak az ESXi-t tartják meg (mondjuk anyagi okok miatt váltanak), bukták a szupportot
- miért szopatnák magukat azzal ezen a szinten, hogy egy nem széles körben elterjedt valamire váltanak (VMware + OpenStack)?
- most, hogy a VMware arról beszél, hogy az OpenStack nem való mindenkinek, minek erőltetnék a fele VMware fele OpenStack megoldást?
- támogatja-e a VMware ezt és ha igen, akkor mennyire?

"Hogy mit raksz be az openstack cuccodba, szerintem az szabadon eldönthető. Ezért is kezdik szeretni."

Ja, csak nem mindegy, hogy a full kiforrott és széles körben szupportált megoldásokat választod, vagy nekiállsz gányolni és a saját bőrödön kitapasztalni a dolgokat.

Én biztos, hogy nem mennék bele ilyenbe, ha én lennék a Paypal és az eBay CTO-ja.

A tapasztalat az, hogy hiba esetén mindig megy a mutogatás a két fél közt. Én ebből biztos, hogy nem kérnék.

--
trey @ gépház

SAS vinyók, HW raid vezérlő, 512MB memóriával, battery backuppal.
Beállítások: scheduler noop a hoston, vhost_net modul van, mindegyik gép virtio driverrel van felszerelve. KSM-et nem használnak, régebben volt teljesítménycsökkenés vele, és már anélkül lett méretezve.
Ext4 és XFS a host fájlrendszer, minden amit lehet alignolva, qcow2 illetve raw imagek.
Egyikkel sincs gond, teljesítményben. Ahol gond volt az SATA (raid edition-ös vinyókkal, de az csak az élettartamra vonatkozik) alrendszerrel rendelkezett. Ez a lokális tárolós.
Storageval is jó, de iSCSI csak iSCSI dedikált kártyával jó, illetve a SAS kapcsolatos külső storageval.
A virtuális gépek cache "none".
Jah,és mindenhol természetesen transparent hugepages beállítás van.

SAS-sal soha nem probaltam, csak SATA-val es ESX-szel szemben.
Ja, meg SSD-vel, azon tenyleg jo volt:)

> Egyikkel sincs gond, teljesítményben

Ugy kerdezem, h mekkora az overhead? Mennyire terheli a hostot az IO mivelet?

> Jah,és mindenhol természetesen transparent hugepages beállítás van.

Nem ismerem, mi az?

Hasznalok KVM-et nap mint nap, de nem fs szerverkent, csak vmi funkcionalis, IO lightos eszkozkent, mint pl. licensz v. vpn szerver. Bevallom, ilyen szinten nem is melyedtem el benne.
Viszont az is igaz, hogy az ESX-nel erre nem is volt szukseg sosem.

Ha lesz idom, ujra meg fogok ejteni egy probat talan. Bar ahogy fejlodik az LXC, szamomra egyre inkabb a jelentoseget veszti a KVM.

10x
tompos

SATA for virtualization is evil... ezt trademarkolni fogom.
A terhelés abból adódik, hogy több gép futtat párhuzamos műveletet, azaz sokkal jobban zsúfolod, így van overhead. Az átlagos fájlműveletek miatt fellépő lassulás kb 10-15%, de ez leginkább sokat író szervízeknél jön elő, és leginkább nagy DB-knél. Én inkább ezért ezt adom meg. Pl PBX-nél a procit eszi a transcoding miatt, de mást nem, vinyóhoz pl alig nyúl. Mailszervernél ugyanakkor más a szitu. Fájlszervernél meg attól függ mit akarnak vele csinálni. Webszervernél azért nincs ilyen gond.
LXC akkor jó, ha jó ugyanaz a kernel. És azért processz szabályozásnál voltak gondok, ha belül is root volt a szolgáltatás, vagy a felhasználó, akkor az izolációnak annyi volt. Meg több dolog miatt. Ajánlom figyelmedbe az alábbi részt: https://help.ubuntu.com/12.10/serverguide/lxc.html#lxc-security

> SATA for virtualization is evil... ezt trademarkolni fogom.

Mint irtam, ESX-szel rendben van.

> A terhelés abból adódik, hogy több gép futtat párhuzamos műveletet, azaz sokkal jobban zsúfolod, így van overhead.

Annyira nem meglepo, ha ez a cel...

> LXC akkor jó, ha jó ugyanaz a kernel. És azért processz szabályozásnál voltak gondok, ha belül is root volt a szolgáltatás, vagy a felhasználó, akkor az izolációnak annyi volt.

Ez igy igaz, nem irtam, h minden problemara megoldas, csak a tobbi egyre inkabb veszit az elonyebol es (szamomra) ezzel parhuzamosan tunnek el a terkeprol.

tompos

Attól függ mi a terhelés, hogy egyáltalán számba vehető-e a sata. Az, hogy mit "adsz" neki, az változó, kinek mi a sok. Pl saját irodában használom a mindennapi rendszereknél, és azért SATA, mert eloszlik a terhelés a futó rendszerek között a különböző napszakokban, így kibírható. Meg azért, mert még nem volt időm migrálni legalább NL-SAS-ra :)
A terhelés egy virtuális rendszer alatt több tud lenni, mert nem veszik figyelembe sokan, hogy sokkal több rendszer üzemel egy fizikai vason, és mindenhol csak 1-2-3 feladat fut, de ha összeadja, akkor lehet, hogy már sikítana, és egy szerverre nem tenné rá. Ha csak alap izoláció kell sok szoftververzió miatt, ami egy vason nehezen férne meg, és nem a security vagy a teljes adat és user elválasztás a cél, akkor teljesen jó az LXC, természetesen a limitációkkal. Én is van, ahol használnám, de nem érte el azt a szintet, hogy még jól lehessen kiváltani minden KVM-es megoldásokat.

Egyéb helyen egyébként nem is használok SATA-val KVM-et, azokat nem vállalom el, ha erre próbálnának vinni. Inkább keresek neki egy eszközfinanszírozót, pl a Grenkeleasinget, vagy olyat, aki velük áll kapcsolatban, esetleg IBM vagy HP partnerfinanszírozás keretében. A virtualizáció olyan játék, ami alá nem ugyanolyan, hanem erősebb vas kell. IMHO. Az előnyöd, hogy 1,5x jobb vasból tudsz spórolni 2 vasat, vagy többet, meg HA-t könnyebb csinálni stb, ami meg más mérőszámokkal kivitelezhető.

Szóval szerintem céges helyen minimum NL-SAS, de komoly adatokhoz SAS, vagy a kettőt keverve, külön storage poolokkal dolgozva lehet még jó megoldásokat elérni.

> Attól függ mi a terhelés, hogy egyáltalán számba vehető-e a sata.

Attol fugg, h sata vagy nem, h mukodik vagy nem. Megpedig a komplett rendszer a legkisebb TCO-val. Minden mas szinte lenyegtelen.

> akkor teljesen jó az LXC

Ezt most nekem elmagyarazod, vagy a partrol olvasoknak vagy miert?
En ismerem es hasznalom az LXC-t meg a tobbit is.

> Szóval szerintem céges helyen minimum NL-SAS, de komoly adatokhoz SAS, vagy a kettőt keverve, külön storage poolokkal dolgozva lehet még jó megoldásokat elérni.

Netto hujeseg. Mindig felhuzom magam, amikor a sajat tudatlansagat es/vagy kenyelmesseget a technologiaval akarja magyarazni vki. Millio lehetoseg van az optimumskalan kezdve onnan, hogy 0 virtualizacio egeszen legmagasabb fokokig.
Hogy allitod, h sata-ra nem lehet rakni, amikor meg a feladatot sem ismered?
Millio feladat van, ami esetben lehet (hw) virtualizalni sata-val (mert egyszeruen a SAS nem hozza be az arat) es nyilvan masik millio van, ami eseten nem lehet.

Ujra irom, ESX vigan (szenvedes nelkul) elvan SATA-n. Szamomra ez a lehetseges kategoria.

tompos

Értem. Bruttó okos vagy. Csak akkor meg minek kérdezel embereket meg témákról, ha van egy véleményed, és a véleménycsere neked az, hogy a másik lecseréli a véleményét a tiedre?
Olcsó húsnak gyakran híg a leve. A SATA-t nem arra találták ki imho, hogy ezeket gyorsan, minőségileg elvégezze. Az olcsón meg relatív. SATA kitünő, akár virtualizált rendszereknek, ha mentést vagy 2 éves archivot tartasz rajta (levelezési rendszerekből néha beleolvasnak stb.) De még itt is az NL-SAS-t ajánlanám. Annyival nem drágább, amennyivel jobb. A SATA-t nem virtualizációra találták ki. Ennyi. Nagy tömegű, olcsó adattárolás. Nem mondom, hogy lehetetlen, de az biztos, hogy nem, hogy nem optimális, de szar, ahhoz képest, amit megfizethetően az NL-SAS tud. Szenvedjen a SATA-val más :)

Miert jobb az NL-SAS mint a SATA? Egy sima LAMP szerver ala vagy monjduk egy kozepesen terhelt adatbazisszerver ala megerheti inkabb amellett donteni? Talalkoztam mar olyan geppel, ami evek ota elvan par SATA diszkkel, es semmi baja nincsen... nyilvan nem valami gagyi lett beleveve...

Tenyleg erdekel, nem ertek hozza.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A saját tapasztalataimról tudok beszélni. Viszont akkor össze is foglalom.
A SATA sima webhostingos környezetben szerintem ár-értékben a legjobb, ha nem virtualizálva fut. A SATA és SATA között is van különbség, mindegyik gyártó - nem brand, hanem akik a vinyókat gyártják - rendelkezik külön céges felhasználásra tervezett sorozattal. Egyrészt a minőségbiztosítása jobb ezeknek, ennek köszönhetően a MTBF mutatójuk is jobb, valós életben is. Bit error rate-ben is jobbak (BERként szoktak kis betűvel hivatkozni rá, ha részletes termékspecifikációt találsz). A SATA, és NL-SAS viszont jobban különbözik. Mechnikailag SATA, azaz nem fog gyorsabban pörögni az NL sas, nem lesz olyan gyors, mint a SAS vinyó. Gyakorlatilag egy enterprise SATA vinyó belül, de SAS csatoló felülettel, annak minden előnyével: teljes tagged command queuing, azaz a fejmozgás optimalizálása az olvasás-írási műveletek újrarendezésével, full duplex adatcsatorna, dual port lehetőség, több hosthoz csatolhatóság. Én első kettőre koncentrálnék. Bár a disk nem lesz gyorsabb, de a SAS interface miatt - na jó, a belső kontroller, ami lekezeli miatt - mégis gyorsabb, mondjuk átlag 20%-kal. Volt akik 30%-ot mértek, de egy kicsit soknak tartanám... Szóval a a SATA felett egy erős határral, de azért jóval a SAS alatt van egy NL-SAS. Kb a gyorsabb működés, ugyanolyan nagy kapacitással. Az élettartamot nem befolyásolja elvileg, hogy SATA vagy NL-SAS. Elvileg, mert a minőségibb cuccok mennek az NL-SAS-ba.
Terhelés szempontjából a saját tapasztalat, meg szerintem másoké is az, hogy a SQL szerverek, és az IMAP userek tudnak odaverni neki. Fájlszerverként, weboldalas kiszolgálásra jó a SATA, de virtualizálva pont azért, mert tele lehet zsúfolni sok mindennel, nem lehet ugyanolyan jól kihasználni, mint egy SAS-t. Persze az árkülönbözet sem mindegy :)

es arban nagyon nagy a kulonbseg a SATA es az NL-SAS kozott? Jo, azt ertem, hogy az NL-SAS olcsobb, mint a SAS, de nyilvan sokszor nem csak a technologia, hanem az ar is dont.

Egyebkent koszonom a felhomalyositast, kicsit oszladozik a kod.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Azert kerdeztelek, mert erdekelt a velemenyed. Leirtam az enyemet is. Problemat jelent?:)

Nem akarom sem a tiedet, sem maset megvaltoztatni. Nem csinaltam tobbet, mint ravilagitottam par allaspontra, amit te ugy tunik v. legalabbis latszolag kihagytal.

Remelem jobban megfelel, atfogalmazom a fenti hozzaszolasomat: dekaval sem lesz elobbre a user SAS-sal vagy NL-SATA-val, ha nincs kihasznalva. Fuggetlenul attol, hogy arra talaltak-e ki.

Ahelyett, h leirod, hogy szar, ird le a miertet:)

10x
tompos

Azzal egyet kell értenem, hogy nem lesz kihasználva, akkor nem éri meg. A gyártók hozzáállása az, és pár diszket már elfogyasztottunk, hogy az NL-SAS-ba jobb cuccok kerülnek. Ez olyan, mint az Intel alaplapok voltak mondjuk 8-10 éve. A FoxConn gyártotta, a jól vizsgázott "alkatrészekből" lettek az Intel alaplapok, a maradékból a FoxConn márkásak... Saját tapasztalat az is, hogy XenServerrel, és KVM-mel is, amit SATA-ról lecseréltünk, mert kényszerből az volt - SAS helyett, mikor nem volt annyira elterjedt az NL-SAS -, ugyanabban a gépben, a migráció után jobban teljesítettek az NL-SAS vinyókkal - iowait-ek kevesebbek voltak, csökkent a load, stb. Egyébként nem venném saját szerverekbe sem azt.

"Nem a replacing vitas, hanem az, hogy melyik komponenst."

Nincs kifejtve. Egyelőre ennyit lehet tudni. Mindenesetre én úgy vélem, hogy 80 ezer szerver és nyílt forrás együtt emelegetése esetén _mindegy_, hogy az egész, vagy csak egy része, ez mindenképpen figyelemre méltó.

--
trey @ gépház

Ebben a formaban teljesen igaz es illik jelezni, azaz azt hogy vmi van, kulonben hatasvadasz.

Ha mar ujsagot ir vki, tegye azt tisztesseggel, hitelesen.

tompos

ui.: Mondom azt tovabbra ugy, hogy valoszinuleg tenyleg dobjak az egesz vmware-es technologiat, tobb cegrol is hallottam pontosan ugyanezt. Sot nemcsak hogy a virtalizacios layert, hanem sokszor egyben az OS-t is valtjak rh -> centos v. ubuntu iranyban.

tompos

s/újságot/blogot

Sosem terveztem újságot írni és nem is tervezek. A linkelt cikkeket továbbra is el kell _mindig_ olvasni. Belekotyogtál valamibe, anélkül, hogy a forrást elolvastad volna. Ha te adsz nekem tanácsot, akkor hadd adjak én is: RTFA. Legközelebb utána kommentelj.

--
trey @ gépház

( Gorkhaan (nem ellenőrzött) | 2013. 03. 26., k – 11:30 )

Egy részük már most is Rackspace-en van a Paypalnek: RHEL meg Citrix-et nyomatnak inkább.

|| "Software is like sex: it's better when it's free." Linus Torvalds || Visit Gorkhaan's Homepage

( psc | 2013. 03. 27., sze – 15:05 )

amugy mi ez az openstack?
hypervisor vagy mi?

Xen, kvn, vmware vagy amit akarsz hypervisornak.
Tud mögé block- és object store-t tenni automatikus replikációval, területi szétdobálással, occó, kici harverből is akár.
Network mgmt és úgy az egész cucc terelgetése, meg amit akarsz.
Mindez pythonból összegányolva, de a vége egész aranyos.
És ott reszeled, ahol akarod/bírod.
Mindez apt-get illetve yum huszároknak.

Azért azt tegyük hozzá, hogy ezek az apt-get és yum huszárok néhány százezer gépes farmokat elmenedzselgetnek azzal az összegányolt python kóddal, amire a vmware klikk & klatty királyok nem mindig képesek, még a letisztult és hibátlan vsphere sdk for perl / powershell -lel sem.

Nem.
A Swift is a része és a Cinder is, még ha ez utóbbi csak most kezd izmosodni.

Grizzly Release:
Volume Create/Delete
Volume Attach/Detach
Snapshot Create/Delete
Create Volume from Snapshot
Get Volume Stats

Grizzly elvileg április 3-án "élesedik".

Abban igazad van, hogy a Cinder igazából egy funkció/API specifikáció, amit valaki(k)nek teljesíteni kell, és akkor integrálódik az eszköz(e/ük) az OpenStack-be. http://docs.openstack.org/api/openstack-block-storage/2.0/content/
Ettől függetlenül azért nem atomfizika pl. egy iSCSI-s pingvindobozt hozzáreszelni.

OK, csak amit irtal, felrevezeto.

> Tud mögé block- és object store-t tenni automatikus replikációval, területi szétdobálással, occó, kici harverből is akár.

Ezt nem a swift csinalja, hanem a shared storage megoldas, pl. glusterfs.
Nem kell hozza semmifele openstack, ez attol meg pont ugyanugy fogja ezt csinalni. Valojaban ebbol a szempontbol az openstack csak bonyolitas.

De javits ki, az openstack-et nem igazan ismerem, csak a masik oldalt.

tompos

Ha idáig eljutottál, akkor az első oldalon megtaláltad volna a választ: az OpenStack 3 modul: (1) OpenStack Compute ami a provisioningot és a virtuális gépek menedzselését végzi; (2) OpenStack Object Storage ami a skálázható storage-ot biztosítja, és (3)Image Service ami a virtuális gépek regisztrációját végzi. Ami ezek alatt a rétegek alatt van, az cserélhető, azaz például elmegy kvm, xen, esx(i) hypervisor felett is.

Basszus, amit én tudok az openstack-ről, az a google első két találatában le van írva. Nem menő akartam lenni, hanem megtanítani az eszkimót halászni, de belátom, hibáztam: nem minden eszkimó alkalmas arra, hogy halász legyen, van amelyik inkább sorban áll az ingyen halért vagy éhen döglik.