Формат за разпечатване

[Тодор Чаушев]

Привет на всички решили да прочетат написаното по-долу!

На 28.06.2010 в ПУ се проведе среща на деканите от университета, лицата отговарящи за развитието на IT технологии във факултетите и IT специалистите. За съжаление както винаги когато се инициира подобно мероприятие за развитието на IT технологиите в ПУ посещаемостта и интереса бяха доста под важността за действия в тази насока.  Но това е мое лично мнение, което между другото изразявам твърде отдавна и ще продължавам да го казвам на глас.

Трудно се възприема, че лицето на университета в интернет и електронните услуги, които предлага са пряко отражение на ВУЗ-а като институция. Виртуалното пространсто е истинско огледало за реалното състояние на която и да е организация в днешно време без значение дали е с идеална или комерсиална цел.

Както и да е да не задълбавам в други теми.

Идеята на срещата бе да се запознаят колегите с възможностите на cloud computing-а и дали да бъдат предприети действия за вндеряване.

Засега положението е по-скоро пас поради невъзможността в рамките на 30-тина минути да бъдат обяснени  идеите, възможностите и перспективите на cloud computing. Нарочно не наричам Cloud computing технология, тъй като представлява по – скоро множество от идеи някой стари други по – нови, подплатени със съвременни технологии.

Опитите за дефиниране на понятието са много. Определението му може да се разглежда като множество от дефиниции всяка вярна за себеси и не изключваща другите. Тази на NIST e наистина най – обхващаща ето линк към нея http://csrc.nist.gov/groups/SNS/cloud-computing (NIST Definition of Cloud Computing)
Най – добрата представа какво е Cloud computing за момента като, че ли е на Simon Wardley http://blog.gardeviance.org
http://www.youtube.com/watch?v=okqLxzWS5R4&feature=player_embedded изложена на OSCON 09

Няма да се спирам на предимствата и недостатъците всеки може сам да прочете за тях.

За да го бъде Cloud computing-а му трябва така наречения Cloud.  Смятам да го наричам IT cloud,  IT облак или ИТ облак, но не и само „облак” както в по-голяма част от специализираната ИТ БГ преса.

Целта на „мероприятието” е в ПУ да изградим един IT облак, използвайки сървърите на факултетите с което да постигнем много по – голяма ефективност при използването им, безотказност и не на последно място икономии от хардуер, захранване и поддръжка. Така ще получим стабилен фундамент на който да стъпят сегашните и бъдещите информационни услуги на Пловдиския университет.

На кратко какво представлява IT облака?  – купчина сървъри свързани по между си с високо скоростна връзка, софтуер за виртуализация и съответните виртуални машини. Идеята е на един физически сървър да работят повече от един виртуален сървър, използвайки по – ефективно ресурсите.

Виртуалните машини нямат представа, че не са физически и нямат представа на кой физически сървър от IT облака работят в конкретен момент, тъй като могат да мигрират в работно състояние навсякъде в пространството на „облака”.

Стига толкова с увода.

Във ФМИ започнахме да „забъркваме” IT облаци от преди началото на годината. Шест месеца по – късно можем да дадем следните резултати за софтуер за управление на IT облака:

 - Разгледахме Elastic Server, oVirt, ConVirt, OpenQRM, ProxmoxVE, OpenNebula, VMware vSphere, Windows Azure, Enomaly's Elastic и редица други

 - Тествахме Elastic Server, oVirt, ConVirt, OpenQRM, OpenNebula, ProxmoxVE имаше и още, но вече ми се губят

 - Спряхме се на ProxmoxVE – най-стабилно се държи, отворен код, безплатен

Ползват се KVM, QEMU върху Debian със ядро 2.6.32-proxmox вклучващо KSM и NBD.

Стига съм писал трябва да оставя място за въпроси.

Чакаме ги

[Атанас Терзийски]

Здравей Тошо, колеги,

Аз бях на тази среща и бях изненадан от резултатите, които споделихте. Осъзнавам колко време ви е отнело това. Разбира се явиха се доста въпроси, които бих се радвал ако дискутираме тук, понеже срещата не беше подходящото място за това. В ПУ определено може да се работи в направление повишаване на ефективността и намаляване на разходи за подръжка на IT услугите. Мога да започна с няколко ориентиращи въпроси, конкретно при вашата постановка.

Можеш ли да представиш някаква схема (или описание) на свързаността/топологията в IT облака който сте изградили. Връзки между между нодовете и между нодовете и сториджа. Етернет ли е или нещо друго? Останах с впечатлението, че ползвате RAID1 за дисковия масив? Това PC ли е или специализиран сторидж?

Правили ли сте опити да пуснете guest OS, разпределена между няколко нода? Има ли някаква работеща паралелизация при KVM?

Хардуера който ползвате с какви процесори е? Те поддържат ли виртуализация?

Правили ли сте някакви bandwidth тестове?

Вярвам по-ценни въпроси ще се родят в хода на дискусията тук.

Пожелавам ви успех и да не се обезсърчавате! Будителството е трудна дейност.

[peachlover]

Здравейте,
по въпросите директно:
1.Схема на облака
Към момента облака представлява :
- NFS Storage (Supermicro X6DHT-G, 2 x Xeon 2.80GHz, 2G RAM, 3ware 9650SE,LAN: 2x Intel 82541GI ) Без Intel-VT (съответно няма KVM)
Машината е с debian lenny, a 2та лана са bond с адрес в частна мрежа.
В Raid-5 (на контролера) са свързани 8 диска по 500G - общо 3Т използваеми.

- Nodes,Head (Възли и глава - на практика разлика няма за това ще ги изброя просто на едно)
5х Supermicro X7DBM, Xeon E5430, 12G RAM, 2x Intel 80003 ES2,  Supermicro мрежов контролер с 2 порта (Общо 3 ползваеми LAN карти, една за сервизна свързаност чрез IPMI)
Всички поддържат Intel-VT

На тези машини 3те останали LAN карти са съответно:
1. Свързаност към NFS Storage
2. Публични адреси
3. Локални адреси на ФМИ

1x Netgear GSM7224R

Така нареченият клъстър (както обясних на срещата) не поддържа разпределяне на един guest върху няколко host машини.
Паралелизация при KVM се поддържа до толкова, че guest машините виждат многоядрените процесори и могат да използват всички ядра.

Тестовете на скоростта които проведохме показаха приблизителна скорост от 1.5 Gb/s при bond-а на сториджа като възлите го натоварваха едновременно.

Всички тестове които сме провели до сега показват че тази скорост е напълно достатъчна за сервисите които използваме.

При наличие на такива които изискват интензивно четене/писане по харда можем да ги хостнем локално върху сървъра на който се изпълняват.

[Атанас Терзийски]

Hi peachlover,

Благодаря ти за бързия отговор. Имате ли наблюдения каква производителност се постига с дисковия масив по NFS при четене/писане на много малки файлове едновременно, фрагментиран трафик, промяна на латентността по време на тестове и т.н. Вероятно в production режим ще трябва да се вдигне капацитета от 1.5 Gbps до сториджа.
Всъщност на мен ще ми е интересно да видя тези неща и мога да съдействам с репорта, ако можете да ми направите някаква виртуална машина на FreeBSD или Debian.

Мислите ли за дублиране на "NFS Storage" машината, като особенно важна в конфигурацията?

По "Supermicro X7DBM" не откривам спецификация, вероятно има нещо неточно или аз не мога д асе ориентирам.

Локално хостване е ОК, но ще е за сметка на една от най-хубавите функционалности на цялата схема - мигрирането на работеща машина в случай на хардуерен проблем в работещия нод.

[peachlover]

Здравей Наско,
Грешката е моя модела е X7DBN.
За дублиране на Сториджа се мисли още от самото начало. 
В текущата конфигурация има още доста неща за изглаждане и те са основно в Сториджа, въпросите на които трябва да си отговорим (задължително и тестово) са:
1. Дали имаме нужда от улеснението което NFS дава по отношение на достъп от други машини (извън самия облак) или е по-добре да се заложи на по-добре представящия се iSCSI от гледна точка производителност.
2. Коя трябва да е файловата система лежаща под NFS (ако той е нашият избор)

Точно в момента провеждам тестове по точка 2 и много ще се радвам ако се включиш тъй като тестовете са доста времеемки.
Спрял съм се на iozone като инструмент за тестване заради изключително дълбоките и подробни тестове, ако имаш желание да се включиш може да се чуем за да обсъдим какво парче от работата ще поемеш ти.

Не е проблем да ти направя виртуална машина но както се досещаш тестовете които провеждаме изискват да се следят физическите машини така че не знам дали ще е от полза направата на виртуална.

И последно - NBD постановка на физическите машини ще ни даде възможност за мигриране и осигуряване на HA дори без сторидж така че пускането на виртуална машина с локален (за възела) диск не мисля че ще е проблем.

[Атанас Терзийски]

... въпросите на които трябва да си отговорим (задължително и тестово) са:
1. Дали имаме нужда от улеснението което NFS дава по отношение на достъп от други машини (извън самия облак) или е по-добре да се заложи на по-добре представящия се iSCSI от гледна точка производителност.
2. Коя трябва да е файловата система лежаща под NFS (ако той е нашият избор)

Ммммда, доста неща предстои да се изяснят. Дори може би техническите решения и тестове да са на втори план пред мащаба, който си поставяме - какво мислим да пускаме занапред и до колко ще лягаме на IT cloud, евентуална степен/възможност за развиване в близките години при взето конкретно решение, допустимо offline време, производителност за различни услуги, натоварване и разбира се бюджет за цялото начинание - както за техника, така и за човешки ресурс. Ако задачата е при наличните ресурси да направим макс. ефективна постановка може, но да не би пък да загубим прекалено много време... не знам, разсъждавам. Вчера попаднах на един интересен поглед над нещата тук... но със сигурност трябва да взема още време да се просветля.

И последно - NBD постановка на физическите машини ще ни даде възможност за мигриране и осигуряване на HA дори без сторидж така че пускането на виртуална машина с локален (за възела) диск не мисля че ще е проблем.

Това не го разбрах. Сигурно ще ми се изясни в хода.

[peachlover]

И последно - NBD постановка на физическите машини ще ни даде възможност за мигриране и осигуряване на HA дори без сторидж така че пускането на виртуална машина с локален (за възела) диск не мисля че ще е проблем.

Това не го разбрах. Сигурно ще ми се изясни в хода.

Грешката е отново моя имах предвид drbd (макар че не съм напълно объркал защото цялата идея отново стъпва на мрежово експортната файлова система)

Идеята е всеки възел в облака да има примерно 2 партишъна който са свързани циклично с останалите възли чрез drbd.

Направих нещо като диаграма за да се изясни (прощавайте за лошото качество все пак го рисувах на MS paint)

Еднаквите цветове показват еднакви партишъни (със съдържанието)
Стрелките показват посока на мирора.

При тази постановка всеки сървър е напълно заменим тъй като неговия локален сторидж съществува и на друг

[Атанас Терзийски]

ОК, мерси. Това DRBD изглежда хитро.

[Тодор Чаушев]

Освен DRBD, разгледахме и Gluster . Христо не го е споменал, но тестовете, които е направил наш бивш колега са показали един много неприятен ефект. Като откачиш единия сървър от HA сториджа (съставен от два соридж сървъра) започва slow response и след минути другия също спира, което както колегата каза: "Ееее гати HA сториджа"

[peachlover]

Тъй като темата започва да се превръща в доста интересна последователност от аргументирани мнения мисля че е време да придадем малко по-голяма строгост на арументите.
Както споменах днешните ми занимания включват точно това - тестове върху файловата система лежаща под nfs-а.
Провеждам тестовете от nfs client гледна точка като това което променям е файловата система на експорта.

Ето четиво за тестовият софтуер:
http://www.iozone.org/docs/NFSClientPerf_revised.pdf

Информация от теста е много солиден материал затова написах няколко скрипта които конвертират log информацията от iozone до csv файл който импортирам в sqlite база.

Предполагам ще ми отнеме няколко дни за завършване на тестовете върху файловите системи които съм си набелязал след което ще предоставя базата за да може всеки да разгледа резултатите.

Проблем ще представляват именно разчитането на тези резултати и даването на еднозначен отговор относно преимуществото на една файлова система пред друга в нашият конкретен случай.

Точно тук смятам да помоля за помощ всеки който има желание да помогне! Имам нужда от начин за измерване на заявките които една операционна система (guest) прави към диска и съответно дисковият си файл. Ако такива изследвания има правени вече също може да се ползват.

Тъй като може да не е станало много ясно ще обясня и с думи прости:
От стартирането си (а защо не още от началото на инсталационният процес) операционната система започва писане по харда, важното в случая е да остановим какъв е вида на тези писания и да намерим сходство с тестовете (бел. обърнете внимание какви тестове прави iozone - написано е още на първа страница от pdf-а за който съм дал линк).
Ако получим статистика в 2 категории read и write по критерии за които и iozone може да тества ще можем да определим най-добра файлова система и да започнем оптимизации както в нея така и по отношение представянето на nfs.


Edit:
И нека после се намерят пак хора които да кажат че Системната администрация не направление което може да вади трудове с научна стойност

[Станислав Желязков]

Здравейте,
Ние от РУ "Ангел Кънчев" използваме за виртуална инфраструктура Vmware Vsphere 4 Update 2.
Разполагаме с едно шаси fujitsu bx600. Към шасито са свързани три блейд модула BX620 S5. Два от тях разполагат с един процесор xeon e5530 2,4GHz и по 8gb рам памет. Третият блейд е с два e5530 процесора и 16gb рам памет. За мрежова свързаност шасито използва 1 pass-trough Ethernet модул, който има 10 порта. Този модул е неконфигируем за това всяка от трите блейда използва само по един Ethernet порт. На всеки един от блейдовете има инсталирана ESX. Всеки блейд разполага с два 300gb Sas дискове, който се в Raid Mirror. Трите ESX хоста са обединени в клъстер чрез Vsphere. За управление на Vsphere се използва Vcenter, който е инсталиран на отделна физическа машина върху Windows 2008 R2. Самият клъстер е свързан към NFS storage, където се намират и самите виртуални машини. Капацитета на nfs-а е 1.73TB. На Vsphere има система за updates на esx хостовете и виртуалните машини, както и система за backup. Vsphere има изключително много екстри и възможности и предополагам всички знаете за тях за това няма да се спирам на тях. Ако имате въпроси питайте. В момента, което ни липсва най-много е switch модул за шасито, за да имат белйдовете повече портове и да се избегне евентуално network redundancy.
Лично аз смятам, че за виртуална инфраструктура е добре да се използва платено решение. Някой от причините за това са добрата подржка, голямата съвместимост и многото възможности. Смятам че когато се прави виртуална структура, тя се прави за доста голям период от време и платеният продукт е гаранция, че подръжката няма да бъде спряна в някакъв период от време. До сега каквито и проблеми да съм срещал с Vsphere съм намирал решията им в сайта на vmware.
Това е като цяло, ако имате въпроси питайте.

[Тодор Чаушев]

Поздрави на колегите от РУ !

Въпроса дали да е платен софтуер или платена подръжка, или пък напълно безплатен вариант, мисля, че е решение, което всеки взима според вижданията си.
Най - сладката част от организирането на IT облак е възможността за лесно преминаване от един софтуер за виртуализация и управление към друг.
След като има изграден storage чрез nfs във всеки един момент може да се започне преминаване към друг софтуер за виртуализация. Повечето разработчици предлагат или формат на диска на гост операционната система, който е разпространен или инструменти с които се конвертира лесно в друг формат.
При това може да се смени софтуера на целия облак в напълно работещ режим без down time.
Първият ми въпрос към колегите е:

Какво се има пред вид "Трите ESX хоста са обединени в клъстер чрез Vsphere"?

 1. high availability - HA
 2. load balancing - LB

Ясно е, че не е high performance computing, тъй като VMware ESX клъстерите се ползват за първите два или някаква тяхна комбинация.
За сега няма решение предлагащо гост машината да ползва едновременно два или повече от възлите.
Предполагам е само единият вид, взимайки под внимание наличния хардуер.

Увеличаването на хардуера от друга страна с политиката на лицензиране на VMWare http://www.vmware.com/download/eula/multicore.html би създало доста финансови проблеми в бъдеще, но това е моята гледна точка.
За бърза справка може да се погледне http://itanalyses.blogspot.com/2009/10/vmware-vsphere-4.html където са разгледани някой неща макар и преди година.
Дори с отстъпките за образователни институции за тези пари може да се назначи един сис. администратор, който да се сбори с някой друг продукт и едновременно с това да върши куп друга полезна дейност.
От друга страна  в поста колегата не е писал коя от версиите ползва Standard, Advanced, Enterprise, Enterprise Plus?
Ето къде са описани http://www.vmware.com/products/vsphere/buy/editions_comparison.html

Ако забележите VMotion и други благинки ги няма в стандартната версия.
Така като се замисля с VMWare софтуер, IT облака на ФМИ в момента ще надхвърли сериозно стойността на железарията. Да не говорим, че идеята е да се направи за целия ВУЗ. Но както казвах това е моята гледна точка.

Та другият ми въпрос към колегата е: На коя версия на vsphere са базирали тяхното решение?

Стига съм писал, че пак се отплеснах  

[Станислав Желязков]

Здравейте,
както казах избирането на платен продукт е мое лично мнение и не ангажирам никой с него, но мисля че беше важно да спомена защо. Смятам че когато се избира софтуер той трябва да работи за теб, а не обратното. Наемането на допълнителен служител ослужнява още повече нещата (поне за нас), защото трябва да се отвори щат и да се извършат други бюракратични дейности. Освен това може да стане така, че този човек да си гриже за тази система и след време да напусне и да се окаже, че другите служители не са наясно напълно със системата и това да доведе до проблеми. С такива случаи сме се сблъсквали много. Това е дълга тема на разговор и всеки има право на различно мнение според вижданията си и по-добре да не я обсъждаме, защото ще се отклоним много  .

Според мен SAN-a е задължителен за всяка виртуална инфраструкура. За сега използваме NFS, защото с това разполагаме, но е хубаво в бъдеще да се мине на iSCSI поне и да се използва специализиран хардуер, а не обикновен сървър.
Vsphere има конвертор за опреционни системи, който ги превърща във виртуални. Поддържа както конвертиране от физически машини, така и от някой други виртуални формати.
Относно клъстера: да Vsphere не поддържа два нода на една виртуална машина и може би това е най-големият ѝ недостатък, но в бъдеще може би с версия 4.1 да се добави и тази опция  ще видим. Разбира се това може да се постигне до известен смисъл с Fault Tolerance. Машината няма да използва ресурсите на двата нода едновремено, но при срив на единия тя веднага ще бъде прехвърлена на другият без никакъв downtime.
Нашият клъстър е конфигуриран за HA и чрез DRS се постига load balancing. Виртуалните машини могат да мигрират свободно, без downtime и за малко време както от хост на хост, така и то storage на storage. DRS е доказана много добра система, която изчислява сама много добре ресурсите и прави необходимите миграции автоматично.
Относо политиката на лицензиране. Да запознати сме с нея. Ясно е че Vsphere не е евтин продукт. Даже бих казал, че е най-скъпият на пазара, но не може да се отрече, че и е най-добрият на пазара за виртуална инфраструктура. До колко ще се използва на 100% зависи изцяло оторганизацията и нейната струкутура. В момента използваме Trial на Enterprise Plus и имаме намерение в близкото бъдеще да закупим лиценз. Както знаете Vmware имат доста добри отсъпки за образувателни огранизация и може да се свали цената значително от посочеите в линка. Свищовският университет имат лиценз и някой, ако се интересува може да се свърже с тях, ако не е проблем за тях може и да Ви предоставят информация за тяхната покупка.

Искам да попитам от къде може да намеря повече информация за избраното от Вас решение? Някак си не можах да намеря какви ОС се поддържат и с какви функции разполага системата. Ще се радвам, ако ми предоставите информация или линкове.
Искам да отбележа, че като цяло ние се стремим към изграждане на нова виртуална инфраструктура със специализирания хардуер за нея. Нямаме намерение за включване на целият ни наличен хардуер в нея. Ще преминаваме плавно към виртуализация на структурата. В нашият случай това е най-доброто решение за момента.
Искам само да допълня някой предимства на Vsphere. Към нея могат да работят допълнителни системи като Vmware View и Fujitsu Zero client (http://ts.fujitsu.com/products/deskbound/zero_clients/zero_client_d602.html), които допълнително в бъдеще могат да разширят виртуализацията на една организация.

[Тодор Чаушев]

Направо по темата без отклонения

В първия пост на темата е написано:

 - Спряхме се на ProxmoxVE – най-стабилно се държи, отворен код, безплатен

Ползват се KVM, QEMU върху Debian със ядро 2.6.32-proxmox вклучващо KSM и NBD

-  тук има грешка в първия пост, става въпрос за DRBD не за NBD (сега го забелязах, ама с тия съкращения ...).


Реализацията ни е Proxmox VE Cluster, подробности могат да се намерят на

http://pve.proxmox.com/wiki/Main_Page
и на
http://forum.proxmox.com/forums/12-Proxmox-VE-Installation-and-configuration

За KVM, QEMU, KSM и DRBD е изписано толкова много, че да цитирам с copy&paste e не професионално.

[Атанас Терзийски]

Здравей Станиславе,
Преди да се насочите към тази конкретна реализация правихте ли по-задълбочено проучване. Разбирам, че нещата са доста комплексни: производителност, първоначална цена, разходи занапред, ефектовност и т.н. още доста парамерти. В момента изнесли ли сте важни услуги на клъстъра. Някакви наблюдения за област на приложение имате ли, например какви услуги все още не можете да изнесете и защо?... Изобщо какво е водещото при вървенето към витруализация и от какво се лишавате, заслужава ли си... (пестене или удобство и на каква цена).
Тези въпроси са интересни за общото планиране и също ги отправям към колегите под ръководството на Тошо, които се занимават в ПУ с витруализация.
Радвам се че се просвещавам около вас момчета,
Успех.

[Станислав Желязков]

В момента на блейдовете имаме 8 виртуални машини включени. 2 от тях са с windows 2008 r2 и са на нашите програмисти и служат за разработване на система. На тях има билд агенти.
Други две са с windows xp и windows 7 64-bit. Това копия на инсталациите на нашите работни станции. Направили сме ги за да тестваме на тях.
Има една машина която е vmware data recovery, която служи за автоматичен backup на другите виртуални машини.
Още две тестови машини едната с windows 2008 r2 другата с RHEL6.
Последната е Davical сървър върху centos.
Смятаме в скоро време да прехвърлим на сферата и още няколко машини с WINS, Antivirus сървър, Jabber и т.н.
Колкото до това кое може да се виртуализира напрактика няма нещо вече което да не може да се виртуализира. Знам че големи SQL сървъри не са препоръчителни за виртуализация понеже създават проблеми, но с windows 2008r2 и ms sql 2008r2 доста от тези проблеми са оправени до колкото съм запознат. Ако имаме един добър, бърз SAN може да прехвърлим всички профили на потребителите на него и да виртуализираме samba сървъра, като той ще служи само за достъп до тези отдалечени профили, което значително би намалило натоварването му.
Относно какъв софтуер за виртуализация сме тествали преди да се спрем на сферата? Признавам, че не съм правил тестове на различни системи, но пък проучвах какви са възможните варианти. Основно съм сравнявал Vmware, Microsoft и Citrix. Като функции първият софтуер определено надминава другите два. Чел съм както различни форуми, така и различни статии и публикации в които се сравняват различните системи и на базата на тях се убедих, че сферата е правилното решение за нас. В момента наистина нямаме много критични виртуални машини на сферата, но както казах по-рано все още сме в тестов период, а сега лятото е точният момент за мигриране на тази системи понеже няма много служители в университета.
Водещото при виртуализацията при нас е да се отървем от по-малко натоварващите сървъри, които предимно са жълти компютри. Така значително ще намалим броят на нашите физически сървъри. Ще останат само професионалните машини, които закупуваме последните 3-4 години. Разбира се с този подход значително ще намалее и нуждата за поддържане на тези сървъри. Системата за backup на сферата е много удобна понеже прави архив на машините много лесно и много лесно се възстановяват. Освен това ако имате няколко машини с еднакви операционни системи и те съдържат множество файлове, които са еднакви по между си системата ще направи backup на тези файлове само веднъж, при което се спестява значително място. Това е може една функциите, които ми хареса най-много.
Според мен цялата виртуална инфраструктура трябва да изпълнява по-голямата част от операциите си автоматично и по-малко да се налага ръчна намеса. Така ще има повече време и ресурси за внедряване на други услуги към нея.

[Атанас Терзийски]

Благодаря ти, че споделяш с нас тези неща. Всъщност окрупняването на услуги (катедрени, факултетски, тестови и т.н.), които вървят самостоятелно върху някакъв ненадежден хардуер върху IT облак е безпорно килър приложение на обсъжданите тук виртуализации. Изглежда все още нямате много опит с виртуализиране на услуги в production режим, но пък все още търсим пътя, нали? Това е целта на тази дискусия...
За мен основното предимство, което разбирам до тук е бързото мигриране/оживяване на работеща система при дефектиране на хардуера. Има доста неща за обмисляне обаче преди да се зарадваме напълно.

Нещата със storage не са толкова розови (или поне евтини). NFS има много предимства, но куца откъм производителност и изобщо тази статия е доста отрезвяваща в това направление.

В момента все още няма надеждно и автоматично прехвърляне на работеща виртуална система на друг хардуерен нод при евентуален проблем в текущия, а квалифициран щат 24/7 все още е утопия далеч не само за университетите.

За да заговотим за надеждност при постановка, в която много от звената са еденичен хардуер трябва да дублираме огледално най-малкото с още една що годе адекватна временна конфигурация, а това може да вдигне доста цената... Ако тръгнем да дискутираме redundancy то всъщност би трябвало да помислим и за интернет свързаността до въпросния облак - маршрутизатори, линии, параметри и т.н. иначе какво печелим при работещ облак зад угаснал маршрутизатор например.

Та в крайна сметка ако кажем че имаме определен бюджет за предоставяне на IT услуги кое освен тия неща трябва да ни е приоритет според теб/вас? Ако трябва да се направи компромис, той къде може да се търси - в определени услуги или група потребители, производителност или капацитет, екстри, нови услуги on demand или изобщо липса на такива, създаване на квалифициран на персонал така щото след 10 години да не обсъждаме нещо, което в момента е хит, а да движим на гребена на вълната... За мен все още е интересно/любопитно областта на приложение на облаците/виртуализацията за нешенските нужди и целесъобразността от инвестиции в това направление.

... ако това ви е интересно бихме могли да преместим малко техническия акцент.

[Станислав Желязков]

NFS определено е вече стар протокол, но за сега и за нас това е единственото най-добро решение. Току що разбрах, че излязала версия 4.1 на сферата.
Ако някой се интересува може да погледне какви са промените на следният линк:
http://www.vmware.com/support/vsphere4/doc/vsp_41_new_feat.html

Направи ми впечатлание, че въпреки че NFS е стар те са направили доста подобрения в производителността за него в тази версия.

[badc0d3d]

Здравейте и от мен,
аз ще допълня с малко информация която посъбрах и преведох за QEMU и най-вече qcow2 формата и как се борави с инструментите на QEMU.
Постарах се четивото да е разбираемо и за хора, не само за админи и техничари така че ако нещо не е написано с изключителна прецизност - не бъдете крайно критични
________________________________________________

Какво е qcow2?
qcow2 е формат за изображения(images) на дискове на емулатора за виртуални машини QEMU.  QEMU може да използва базов image който се използва само за четене, и всички промени да бъдат записвани в qcow2 image. qcow2 е най-гъвкавият сред поддържаните формати от QEMU. Можете да го използвате за по-малки имиджи, с допълнително 128-битово AES криптиране, zlib компресия и snapshots на виртуалната машина.
Употреба и създаване на QCOW имиджи чрез qemu и qemu-img
qemu-img е инструмент който върви ръка за ръка с qemu и чрез него се създават qcow имиджите.
Имиджът на хард диск за виртуална машина най-общо може да се каже, че представлява файл на физическа машина съдържащ характеристиките на реален такъв. Има още доста формати имиджи който се ползват както от open-source приложения като qemu и VirtualBox, така и частни като VMWare.
Създаването на имидж става много лесно чрез следната команда:
qemu-img create -f <формат> <име-на-файла-имидж> <размер>
пр. qemu-img create -f qcow2 windows.qcow2 10G
което ще създаде файл с име windows.qcow2, който ще съдържа имидж от тип qcow2  с размер 10 гигабайта.
Конвертиране в различни формати чрез qemu-img
qemu-img поддържа следните основни формати(версия 0.12.3) : cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 parallels nbd raw и още няколко допълнителни.
Както виждате qemu-img поддържа повечето известни формати като VDI(VirtualBox) и VMDK(VMWare) и много удобно можете да конвертирате от един в друг формат при нужда.
Конвертирането от един в друг формат става по следния начин
qemu-img convert <име-на-файла-за-конвертиране> -O <изходен-формат> <име-на-изходния-файл>
Ако използваме примерния файл по-горе windows.qcow2 можем да направим следното
пример: qemu-img convert windows.qcow2 -O vdi windows.vdi ще създаде удобен за VirtualBox имидж.
пример: qemu-img convert windows.qcow2 -O vmdk windows.vmdk ще създаде удобен за VMWare имидж.
Използване на базови имиджи
Базовите имиджи ще бъдат много удобни в случай, че сте направили нова чиста инсталация на дадена операционна система и искате да я пуснете нова машина със същият имидж. qcow използва техниката Copy-On-Write(cow) от която пройзлиза и името на формата - а именно, четене на базовият имидж и при нужда от промяна, се записва в нов имидж.
Ако вземем примера по-горе при създаването на имиджа който направихме -
qemu-img create -f qcow2 windows.qcow2 10G
и примем че на него имаме току-що инсталирана работеща операционна система, вероятно ще искаме да й направим копие върху което да работим с промените за да се възползваме от тази възможност на qcow2 . Ще го направим по този начин със следната команда:
qemu-img create -b windows.qcow2 -f qcow2 windows-work.qcow2
и ще съответно получим нов имидж с име windows-work.qcow2.
Забележете - новият имидж няма да бъде голям колкото оригиналният - 10гигабайта - а след създаването му ще варира от 50 до 200 килобайта, като нараства с програмите и всичко останало което копирате на този имидж.
Когато използваме windows-work.qcow2, при четене реално ще ползваме оригиналният имидж който е послужил за шаблон - windows.qcow2 - като той самият остава непокътнат при работа с пройзводният. Всички промени ще се записват в windows-work.qcow2.
Snapshots      
Snapshot-ите(снимки) са подобни на copy-on-write техниката, с изключение на това че върху оригиналният имидж може да се записва а не върху самите снапшоти. След като сте свършили работата преценявате дали искате да запазите промените които сте направили или да върнете предишното състояние на имиджа през периода в който е по време на снимката(snapshota).
qemu-nbd
qemu-nbd e инструмент който може да послужи за export при миграция на виртуална машина като network block device. След това имиджът може да бъде свален чрез SelfImage – (freeware за Windows)
пример: изпълнявате qemu-nbd -t /път/към/имиджа.qcow2 и на друга физическа машина използвате SelfImage с IP адреса на машината на която е имиджа и порт 1024

[Тодор Чаушев]

Поста на badc0d3d е на новият ни колега Еди Фесчиян, забравил е да се представи, но му е простено имайки предвид годините му в момента  

Със това съм напълно несъгласен

В момента все още няма надеждно и автоматично прехвърляне на работеща виртуална система на друг хардуерен нод при евентуален проблем в текущия, а квалифициран щат 24/7 все още е утопия далеч не само за университетите.

може да бъде демострирано от всяка що годе читава реализация на софтуер за организиране на IT облак.

Дори има писан софтуер за оптимизация на използваните ресурси, който се ползва в БГ фирма предоставяща VPS услуги. Алгоритъма е разработен от преподавател на ФМИ занимаващ се с оптимизационни задачи. Така напълно автоматично се разпределят vвиртуалните машини по физическите и освен failover се осигурява възможност за икономично и целесъобразно използване на ресурсите. "Облака" сам пали и гаси сървъри когато е необходимо, от това по автоматизирано не виждам.
А дали е надеждно ?   Ами сигурно е по-надеждно от нашите услуги, които предоставяме. Все пак хората с това си вадят парите и досега да са изхвърчали от пазара. В интерес на истината имат много малък администраторски щат, имайки предвид броя им клиенти.