Привет на всички!
Някой да има опит с използването на RAID контролер в хаки? Четох, че няма драйвери за не-маковски контролери. Остава използването на real Mac контролер. Намират се разни обяви за такива втора ръка. Въпросът е дали има шансове за успех начинанието. Ако някой е опитвал, моля да сподели инфо.
На твое място щях да процедирам така:
Забождам хардовете на дъното и оттам бой с 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? От това, че е хаки или има ограничение някакво някъде?
Пропуснах да спомена, че всички тестове са правени с големи файлове.
От протокола идва разликата. 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)
:) Навлизаш в дълбоки води
Не знам, не съм правил линк. Но според мен няма нужда клиентите да имат, ако направиш линк само на сървара ще подобриш работата му при обслужване на няколко клиента, скоростта с един клиент няма да се подобри освен ако и той има линк агрегейшан.
Ако в момента имаш две ланки на хакито просто опитай да направиш линк от 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-то, макар че ми коства доста усилия да го настройвам.
Привет,
от известно време съм в подобни на твоите борби. Ще ти споделя аз до какви изводи стигнах, след като пробвах доста варианти, а ако ти е от полза ще се радвам да съм помогнал.
На кратко в офиса имаме 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 Гб мрежови карти на сървъра, но за да можем да гарантираме сигурна скорост към всяка работна станция трябваше да накичем много мрежарки на сървъра, а нямаше физическо място. Сега на всяко МАК Про мрежовите кари са линкнати и си работят бесупречно.
Моля да ме извиниш, ако всичко, което написах не е много подредено, но е доста информация и не знам до колко успях да я синтезирам.
С две думи, както казах по горе, с линукса нещата ни се получиха най-добре. Фенове сме на МАК, но понеже не е за забавление, а с комерсилна цел, малко загърбихме любимата операционна система за сървърните ни нужди :). А и моля да ме извиният спецовете в областа, че не обяснявам на професионален език, но аз самият не съм специалист в тези проблеми, по скоро ми се наложи да се сблъскам с тях.
Поздрави.
Ех,че не съм бил аз там да ви покажа какви чудеса върши FreeBSD + ZFS!
Цитат на: HQ - 22-06-2014, 13:02:48
Ех,че не съм бил аз там да ви покажа какви чудеса върши 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 ?
Привет,
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тб, но вероятно си се сетил за това, а и от опит знам, че много бързо ще ти отеснее пак :).
Поздрави.
Играл съм само с Дебиан и FreeBSD! Даже отделих много време на Debian k/FreeBSD което е бсд ядро с линукс около него. Всичките поддържат ZFS. Убунто е дебиан,тъй че нещата там са същите. Това което правя са само домашни експерименти,но има успех. Нямам представа какви биха били скоростите, тепърва ще правя мирор с 2 харда като належащ ъпгрейд и очаквам скоростта да е близка до 12 gbps (като за 2 сата тройки) . Едно е сигурно - лесно се сменя диск от масива, винаги можеш да прибавиш диск който да се присъедини към пуула(нещо като jbod), компресия,дедупликация,prefetch, 1mb cluster size,snapshots, ...
Ето ти един блог,от който ще научиш 90% от това което ти е нужно за изграждане на FreeBSD със ZFS:
http://www.aisecure.net/
Послушах съвета ви и започнах проекта по изграждане на сървър с FreeBSD със ZFS. FreeBSD-то се оказа нелоша система, а и това, че MAC OS е изграден на негова основа улеснява работата. Не че пак не пада четене, хубавото е че наученото мога да използвам и при МАС. Използвам FreeBSD 10, като го инсталирам Root on ZFS. Всъщност пробвах и без ZFS в основата, а само на сториджа. Първо пробвах с 2 диска в mirror, после с 3 - 1 за OS и 2 за сторидж пак в mirror. Идеята за snapshot-ите и бързината с която се правят много допада.
Оооообаче - скоростите нещо ми убягват. Правих различни тестове, за шерване ползвам NFS, но не успявам да докарам по-висока скорост от 25-30МБ/сек за писане и 60МБ/сек за четене. Не съм опитвал с други протоколи за шерване, нали този е най-бърз...... Продължавам да ровя из темите за оптимизация и настройка на ZFS, но получените скорости при мен ми се виждат твърде ниски дори и за базова конфигурация. Самата машина е достатъчно бърза (тази от 3-тия пост) - ASUS P6T WS Professional + CPU Xeon E5645 (6 core) + 3х4GB noECC RAM.
Между другото у дома, на мини от средата на 2010-та с 2 х 1ТБ сложих OpenZFS на Mavericks (ZFS-то е на mirror от 2 дяла на 2та харда) - държи се много добре, скоростите са определено по-добри - на писане 60-65МБ/сек, на четене 80-90 (говоря за скорости при големи файлове).
С какво да си изтествам скоростта на ZFS сториджа вкъщи? Имам гигабитова връзка към него, евентуално нея да напъна или мога директно с dd (примерно) да засега трансфер локално на сървърчето?
Аз пробвах по различни методи:
- през мрежата с Xbench и Helios LAN test - двете дават сходни резултати, 25-30 писане, 60 четене.
- директно в сървъра, без прехвърляне по мрежа - тествах с bonnie++, dd (копиране на файл от едно място на друго), /usr/bin/time -h dd ...... - 1-то дава 62/125 (писане/четене), 2-то 66 писане, 3-тото (нещо не му схващам логиката, твърде различни резултати дава) 85/600 писане/четене.
Опитвах и без ZFS, тогава скоростта през мрежата се нормализира 75-80/85-95 писане/четене. Тестове на скоростта локално в сториджа без ZFS не съм правил.
Съвет:
1) спрете atime:
zfs set atime=off tank
2) Използвайте компресия LZ4 и LZJB , не използвайте GZIP или другите защото са бавни и тромави. Лично аз залагам най-много на lz4 защото е най-нова и има много плюсове, особено за /var/log /var/mail и там където има много наброй малки файлове е направо чудесна.
3) разрешете prefetch ако сте с >4 гб рам:
echo '"vfs.zfs.prefetch_disable=0"' >> /boot/loader.conf
Имаше и още неща като задаване на част от рамта за кеширане от ZFS, задаване на 1MB cluster size но на този етап не ги препоръчвам защото не съм ги тествал а и се увеличава шанса всичкия тунинг да заработи в обратна посока, но възможности за пипане колкото искаш. Ето нещо за начало : https://wiki.freebsd.org/ZFSTuningGuide .
При всички случаи ZFS е по-бавна от познатите ви дървени журнални системи, защото все пак е от ново поколение, използва много рам и процесор, но пък предлага завидна сигурност на работа.
Според моите груби изчисления една система с 4-8 ядра, 16 гб рам и 11 харддиска RAIDZ3 би била по-бърза и 100 пъти по-сигурна от същата с линукс и RAID5+EXT4 фс например.
Ако бих могъл да бъда полезен с друго ще се радвам да помогна!
Благодаря HQ, ще опитам .....
По отношение на съвет 2 - опитах и Lz4, и Lzjb, и Gzip с различни нива на компресия, но ефекта беше все отрицателен, т.е. - забавяне. Повечето тестове правя през мрежата, при това с големи файлове. Компресията конкретно тествах с 1ГБ файл, понеже 3/4 от файловете, които ще се записват на бъдещия сървър са 100МБ+. Вярно, че заеманото място пада с 20-30%, но приоритет ми е скоростта. Да не би компресията да има ускоряващ ефект само при малките файлове? Ей тук - https://calomel.org/zfs_raid_speed_capacity.html - четох разни неща за компресии и ускорение, НО .....
Полезно четиво, ще го погледна!
Щом скоростта ти е важна, спри компресията! Все пак и без това ефекта от нея е нищожен. Трябва да знаеш,че zfs е жива и self-tunable система. Скоростта ти е оптимална за конкретната конфигурация и малко вероятно да я подобриш значително. Пак ти казвам, всичко е свързано с допълнително надграждане на системата - повече хардове и повече рам които никога няма да са достатъчно.
Гледай винаги да ъпдейтваш системата и да имаш най-висока версия на zpool защото с всеки ъпдейт има подобрения, нови фийчъри и вярвай ми, работят усилено върху бързодействието!