RAID контролер на хакинтош

[Пиф]

Привет на всички!
Някой да има опит с използването на RAID контролер в хаки? Четох, че няма драйвери за не-маковски контролери. Остава използването на real Mac контролер. Намират се разни обяви за такива втора ръка. Въпросът е дали има шансове за успех начинанието. Ако някой е опитвал, моля да сподели инфо.

[HQ]

На твое място щях да процедирам така:
Забождам хардовете на дъното и оттам бой с Disk Utility (преди инсталацията) докато успея да си харесам 0 или 1 да е райда . При хардуерните райдове нещата които могат да се объркат са на квадрат спрямо софтуерните и ти трябва драйвер пък и не е гаранция че ще успееш да замениш някой диск безболезнено при нужда.
Успех!

[Пиф]

Благодаря ти @HQ,
В момента използвам почти същата конфигурация като препоръчаната от теб, с тази разлика че имам допълнителен диск само за OS-а. Всъщност моя грешка е, че в първия си пост не уточних как са сега нещата и какво целя с промените.
Значи, в момента използвам един диск 320GB за операционната с-ма + 4х3ТВ конфигурирани в RAID10 с Disk Utility. Идеята за използване на RAID контролер цели 2 неща:
1 - повишаване на скоростта на трансфер (основно)
2 - увеличаване на капацитета с добавяне на още дискове
Компа се ползва комбинирано - за файлов сървър с прилично голямо натоварване и за работна станция.
Дъното, което ползвам е ASUS P6T WS Professional + CPU Xeon E5645 (6 core). Ако тръгне да се получава с RAID-а мисля и  link aggregation да опитам, да вдигна скоростта към мрежата.
В общи линии това съм замислил....

[Пиф]

Днес реших да потествам малко машината за да видя къде всъщност са и слабите места. Трябваше да го направя преди да подкарам плановете с промените, но - по-добре късно, отколкото никога!  ;D
Използвах HELIOS LanTest и Xbench.
- скорост на четене/писане на RAID-a (RAID10, 4х3TB) - средно 140/170 MB/s
- скорост на четене/писане на основния диск (с OS-a, 500GB, в предния пост по грешка съм го посочил като 320GB) - средно 80/75 MB/s
Разликите между показанията на 2-те програмки са от порядъка на 10-15%, затова и пиша, че скоростите са осреднени.
При тест на мрежовата скорост показа следното:
- скорост на получаване(четене)/изпращане(запис) - средно 80/40
но, това което измерих май не е точно тест на мрежовата скорост. Пускам всяко от приложенията на друг комп и им задавам като дестинация шернато у-во от хакито. И реално показанията са скорост на четене/запис върху шернат диск, но на това влияе както мрежовата скорост, така и скоростта на работа на самия диск. Не съм сигурен, че това е начина за тестване на LAN, макар че на сайта на Хелиос пише "test and measure performance of AppleShare services". Та по въпросния начин (като шернати у-ва) тествах и основния диск и RAID-a на хакито, показанията са почти едни и същи. Изводът, който си правя е, че скоростта по LAN ограничава всичко и че там е слабото място. Мога ли по някакъв начин да забързам LAN-a?
Преди време си бях правил едни експерименти с Ubuntu server, инсталиран на същата машина, като вместо RAID10 имаше RAID5. Скоростта на четене и запис от и към RAID-a през мрежата беше от порядъка на 100-110 MB/s.
Откъде според вас иде тази голяма разлика в скоростта с/о Ubuntu? От това, че е хаки или има ограничение някакво някъде?
Пропуснах да спомена, че всички тестове са правени с големи файлове.

[Metal]

От протокола идва разликата. AFP е бавен.
По мой наблюдения са подредени горе долу така:
1.NFS - Unix Network File System
2.SMB/CIFS - (Server Message Block) т.е. шера на уиндоуса, обаче след версия 2 т.е. от боза Виста нагоре
3.AFP - имаше леки подобрения през годините но в крайна сметка изостана
4.SSH2
5.FTP

Това е и причината Apple да преминат към SMB в Mac OS 10.9
При това трябва да се отбележи, че опън сорс имплементацията е по бавна от тази на майкрософт windows-windows е най-бързо. Епъл стъпват върху опън сорс версията но подозирам, че са направили свой подобрения.

[Пиф]

Протокола при тестването е SMB, хакито е с Mac OSX 10.9 и OSX server 3.01. Пробвах и с AFP - при големите файлове е почти същото (по-бавен с 2-3MB/s), но при малките скоростта пада наполовина.
Лошото е, че от предишните тестове с Ubuntu не помня тези стойности (100-110MB/s) с какъв протокол ги постигнах. Пробвах ги тогава и 3-те май .... (NFS, AFP - с Netatalk, SMB - с Samba). Но тогава нещо ми дойде в повече този линукс и го зарязах, започнах темата с хакито, но сега пък скоростите не ми харесват ....   ;D
С последното изречение по никакъв начин не искам да загегна линукс обществото и феновете му, Linux е система с неограничени възможности, но за човек, който му разбира. Аз тогава започнах от А - Б, още повече че сложих Ubuntu server и за всеки команден ред рових из нета.
Възможностите, които виждам за ускоряване на LAN-a са 2:
1 - Връщам се на тема Ubuntu server. Но, тестовете които преди правих бяха по времето когато си купих първия мак. Като нов потребител тогава съвсем слабо познавах възможностите и функционалностите на мак. Та съмненията са ми в посока, дали протоколите за шерване при убунту поддържат всичките функции, които подсигурява шерването при мак. И дали всъщност ще има повишение на скоростта на трансфер трайно и при всички приложения.
2 - Да оставя хакито, и да пробвам с LACP, което би трябвало да удвои скоростта през LAN-a. Лошото е, че трябва да сменя суйча с такъв, който подържа LACP, а те пък не струват много малко. Там пък друго не ми е ясно - достатъчно ли е да се сдвои (строи) връзката м/у хакито и суйча или трябва да се направи същото и с връзките към клиентските компютри. (започвам да виждам снизходителни усмивки по лицата на разбиращите  :D)

[Metal]

 :) Навлизаш в дълбоки води
Не знам, не съм правил линк. Но според мен няма нужда клиентите да имат, ако направиш линк само на сървара ще подобриш работата му при обслужване на няколко клиента, скоростта с един клиент няма да се подобри освен ако и той има линк агрегейшан.
Ако в момента имаш две ланки на хакито просто опитай да направиш линк от System Preferences - Network - Manage Virtual Interfeces. Поне ще знаеш дали трябва да сменяш рутера.

Аз намирам скоростта от 80MB/s за добра, 20% повече не си заслужават главоболията от смяна на хардуер и софт.
Друга опция е да вдигнеш размера на пакетите MTU ако това се подържа от сървара, клеинта и рутара.

[Пиф]

Все пак му сложих Ubuntu server  :)

Използвам NFS и AFP. При AFP скоростите на запис/четене през мрежата са 95/95 MB/s, а при NFS - 125/95 MB/s. Притесненията ми за AFP-то под линукс май се оказаха неоснователни, засега не откривам нищо куцо. При NFS-то нещо пермишъните ми се опъват .....

Хакито засега го зарязвам, искам да намеря едно старо Pro, което да накича за сървър. Все пак ще се използва за комерсиални цели и не е много редно да е хакМАК, а риълМАК. Но дотогава ще е Ubuntu-то, макар че ми коства доста усилия да го настройвам.

[andonov]

Привет,
от известно време съм в подобни на твоите борби. Ще ти споделя аз до какви изводи стигнах, след като пробвах доста варианти, а ако ти е от полза ще се радвам да съм помогнал.
На кратко в офиса имаме 4 сторидж сървъра. Един държи около 100 терабайта, един около 40 терабайта и два са по около 10 терабайта. Всичко е RAID 5. Трите са през хардуерни контролери, а единия 10 Тб е през софтуерен. Минах през всички варианти -   MAC OS Server (през риъл мак про, не през хакинтош), Windows Server и Линукс. Към момента моите наблюдения са следните, но преди това да кажа, че около 80 процента от работните станции са  MAC Pro, a останалите са уиндоус. Та наблюденита и тестовете при реална работа са следните - най лесно като мениджмънт е мак про сървър, но е много трудно да увеличавам обема на дисковото пространство, а при нас се налага относително често, или пък е много скъпо. Същото е и за увеличаване на скоростта по мрежата. Проблемите са по скоро хардуерни. Поради тези основни причини се отказах от МАК ОС Сървър. Около 4 години преди това, бяхме на Уиндоус сървър. Нямахме някакви сериозни проблеми до момента в който трябваше да увеличаваме скорост на достъп по мрежата като и дефиниране на юзерски права. Оказа се доста трудна за нас работа. Множество настройки, рестартирания, забивания и .. не особенно добър ефект. Не изключвам и тънкия момент, че не сме особени фенове на уиндоус и лесно решихме да преминем на Линукс. Е, като първи досег с това чудо и ние се метнахме на Убунту. Уви и ние като теб установихме, че това не е за хора, които не са навътре с линукс. В крайна сметка след много проби и грешки и помощ от добри приятели с познания в сферата на линукс се установи, че е най добре да разкараме убунтуто и да сложим нещо от рода на REDHAT. При тази постановка установихме, че ако юзерите ти не споделят едновремемнно едни и същи файлове и проекти най добре е  iSCSI.  Mac OS  си го виждат все едно са локално закачени дискове. Могат да си го форматират и ползват все едно е физически закачен към тях диск. Разбира се, при тази постановка, не е невъзможно да се ползва един файл споделен от различни юзери, но всеки след първия юзер, който ползва файла го ползва през първия и ако този първи юзер се рестарира или изключи по някаква причина, другия юзер увисва и той :). Линк агрегейшъна на мрежови карти между МАК ОС и Линукс работи без никакви проблеми. В момента единия от сървърите ни е като iSCSI Target и двете мрежови карти на МАК ПРо клиентите са линкнати. Работи без никакви проблеми. Единсвеното "неудобство", е че трябва за всяка клиентска машина да отделиш около 90 долара за iscsi initiator за МАК Машините. За уиндос клиентите, до колкото разбрах, май има безплатни варинати, но на нас не ни се наложи. Ако работния ти процес налага споделяне на еднакви файлове и проекти едновремено от няколко юзера, то установихме, че за МАК машините най добре е NFS, в интерес на истината и с AFP си роботеше, но за сега сме с NFS. Sambata гълта страшно много оперативна памет и освен това при директории с много файлове (при нас има директории с над 100 000 файла) отнема много време на МАК клиента да ги види. Допълнително към това, нещо се бъгваше като от време на време не рефрешва коректно или пък при запис на файл на сървъра не можеш да го видиш веднага, все едно не е там. Това се случваше само при МАК клиентите. При уиндоус клиентите си беше наред, но за нас не беше вариант при преобладаващо мак клиенти. Затова изоставихме самбата и минахме на nfs. За сега нещата са добре, но това е от около седмица и все още се води тестов период :).
В крайна сметка, накратко казано, от линукса за момента сме най-доволни. Не е най "юзер френдли" за мениджмънт, но пък като се настрои добре няма нужда да го ръчкаш често. Разпознава без проблеми почти всякакъв хардуер за ъпгрейд (при МАК не беше много лесно с хардуера, или няма избор или е много скъп). В интерес на коректноста ще кажа, че едния от сървърите ни, си остана на уиндоус, но към него останаха вързани само уиндоуските работни станции. При тях проблема със скороста и  линк агрегейшъна, който се оказа кошмарен под уиндоус, решихме като сложихме 10 гигабитови мрежови карти, премахнахме суича и всяка машина свързахме директно със сървъра. Така получихме около 300 мб/сек към всяка машина за четене и писане и за сега ни устройва. При тази постановка ограничението дойде от сървъра. Той не може да даде повече от това. Проблема със скороста в останалата мрежа решихме като на другия сървър сложихме 2х10 гигабита мрежови карти в линк агрегейшън и през някакъв, май мениджъбъл суич подадохме към всяка работна станция гарантирана скорост от 1 до макс 2 гб (в линк). Преди това опитахме линк агрегейшън на 1 Гб мрежови карти на сървъра, но за да можем да гарантираме сигурна скорост към всяка работна станция трябваше да накичем много мрежарки на сървъра, а нямаше физическо място. Сега на всяко МАК Про мрежовите кари са линкнати и си работят бесупречно.
Моля да ме извиниш, ако всичко, което написах не е много подредено, но е доста информация и не знам до колко успях да я синтезирам.
С две думи, както казах по горе, с линукса нещата ни се получиха най-добре. Фенове сме на МАК, но понеже не е за забавление, а с комерсилна цел, малко загърбихме любимата операционна система за сървърните ни нужди :).  А и моля да ме извиният спецовете в областа, че не обяснявам на професионален език, но аз самият не съм специалист в тези проблеми, по скоро ми се наложи да се сблъскам с тях.
Поздрави.

[HQ]

Ех,че не съм бил аз там да ви покажа какви чудеса върши FreeBSD + ZFS!

[andonov]

Ех,че не съм бил аз там да ви покажа какви чудеса върши FreeBSD + ZFS!

Всщност си много прав. Установихме го това, което казваш. Единият от сървърите (iSCSI-то) в основата си е точно ZFS.
Установихме, че би било чудесно да минем на  ZFS и на другите сървъри и да разкараме Хардуерните контролери, но не можем да измислим къде да изсипем временно около 150 тераайта инфо докато успеем да сетнем нещата наново :). Така, че за сега се съобразяваме с даденостите. Ако колегата ПИФ не е напълнил масива все още, да минава на предложеното от теб :)
Потвърждавам от лични наблюдения, че софтуерен райд и  zfs са си благинка. няма го треперенето какво ще стане ако хардуерния контролер сдаде багажа. Във времето имахме известни хардуерни сътресения и сега, колкото и абсурдно да звучи държим по една бройка от същите контролери за резервни. Че никой не ни гарантира, че по нов модел пък бил той и на същия производител ще разпознае масивите от старите контролери. За сега сме решили за следващия по сериозен ъпгрейд ще се действа както казва HQ - ZFS.

[Пиф]

@andonov, много благодаря за подробно споделената информация !
Моят масив е далеч по-скромен - 8 ТБ, съставен е от RAID10 4х3ТB + RAID1 2х2ТB. Но определено не ми стига. Старата информация е местя на външни дискове, правя им бекъпи .......   неудобна работа общо взето. На въпросното хаки съм му запълнил всичките SATA порта (8 броя) и няма повече накъде. Затова и започна битката за място, скорост и законност.
Междувременно му бях сложил пак едно убунту, но го изтраях 3-4 дни, не можах повече този път. NFS-то показа добра скорост, но тези настройки и това ровене за всяко нещо направо ме убиват. Разбирачите веднага ще ме причислят към групата дефинирана в този цитат от пост в замунда във връзка с новия филма за Стив Джобс - "Иначе добре беше усвоил правилото, че направиш ли нещо, което всеки идиот може да ползва, то ще бъде използвано само от идиоти :) Не случайно мишките и тъчпадите на Apple имат само един бутон, както и телефоните им. Смята се, че за средният потребител на марката различаването на "ляво" от "дясно" е твърде изтощително усилие... "....  макар, че точно това му е гениалното на Стив, предложи нещо (неща) семпло, интуитивно, просто за употреба, става и за деца от 3 до 93 години. Но това е друга тема, отплеснах се ....
Та, убунто-то го махнах за пореден път. Дъното което ползвах до тогава беше ASUS P6T WS Pro, с 6 интелски SATA порта и 2 SAS Marvell, последните така и не можах да ги подкарам под Mac OSX. Това дъно се оказа и с повреден LAN, затова и скоростите бяха доста ниски и често чупеше мрежата. Подмених го с ASUS P8Z68-V Pro и отново върнах МАС-а, този път скоростите с AFP са от порядъка на 95-115 MB/s и в двете посоки, което си е малко под убунту с NFS. А и при това дъно подкарах и 8-те SATA порта. Но лошото е, че пак не стигат - ни мястото, ни скоростта, ни решението е по правилата. Линк агрегейшъна ще го използвам, щом казваш че го ползвате и всичко е ОК, търся суич сега, че моите не стават.
За ZFS-то - много малко неща знам, общо взето това че откъм сигурност е най-доброто решение. Ще поровя да видя какво ще открия. @HQ, имаш ли наблюдения как са скоростите на четене/запис спрямо софтуерен RAID, изграден в убунту примерно ?
Лошото е, че инвестициите нарастват лавинообразно с/о TB-те и MB/s-те.

[Пиф]

А да сте ползвали тази гад - MacZFS ?

[andonov]

Привет,
MacZFS не съм ползвал и нямам никакви наблюдения въргу него.
относно сравнение между ZFS и Убунту -HQ да каже, ако е тествал, аз не мога да кажа. Убунтуто го разкарахме много бързо. В момента мога да сравнявам,  донякъде, ZFS под  REDHAT с 6 диска и Масива с LSI Raid контролер с около 60 Диска към него пак под REDHAT.
Но сравнението няма да е много коректно защото един масив от 20 диска  при всяко положение ще даде повече трансфер от масив с 6 диска.
Не знам с какъв бюджет разполагаш, но лесен ъпгрейд на пространство можеш да получиш примерно с LSI 9300-4i 4 ports HBA 12Gb/s (варианти много, това е първото което мернах)  + JBOD шаси примерно с 12 броя 3.5 инчови гнезда. Това е около 1000-1200 долара без цената на дисковете и получаваш възможност да сложиш 12 бр. макс 4Тб дискове - ще имаш около 40 ТБ полезен масив в РАИД-5 или пък да си го "нацепиш" както на теб ти е удобно. Хувабото е че под линукс и ZFS  не е задължително да слагаш всички дискове. започваш с примерно 4 диска и във времето според нуждите ти експандваш. Друго прединство е че LSI-a не е РАИД контролер а е само Хост. И дори да изгори, всеки следващ модел не би имал проблем да види масива. Поне така ми обясниха на груба теория.
Друг вариант е да замениш старите си дискове с 4тб, но вероятно си се сетил за това, а и от опит знам, че много бързо ще ти отеснее пак :).
Поздрави.

[HQ]

Играл съм само с Дебиан и FreeBSD! Даже отделих много време на Debian k/FreeBSD което е бсд ядро с линукс около него. Всичките поддържат ZFS. Убунто е дебиан,тъй че нещата там са същите. Това което правя са само домашни експерименти,но има успех. Нямам представа какви биха били скоростите, тепърва ще правя мирор с 2 харда като належащ ъпгрейд и очаквам скоростта да е близка до 12 gbps (като за 2 сата тройки) . Едно е сигурно - лесно се сменя диск от масива, винаги можеш да прибавиш диск който да се присъедини към пуула(нещо като jbod), компресия,дедупликация,prefetch, 1mb cluster size,snapshots, ...
Ето ти един блог,от който ще научиш 90% от това което ти е нужно за изграждане на FreeBSD със ZFS:
http://www.aisecure.net/