Миграцията от RAID1 до RAID5 се оказа многократно по лесна от колкото си мислех 🙄 В общи линии са 5 прости стъпки малко чакане и 1 една бира за кураж.

При мен системата има създаден RAID масив md0 в който участват 2 диска sda и sdb. Ще добавя към тях 3-ти sdc за да създам RAID5 от 3 диска. Като цяло тая акробатика е с научна цел на виртуалка още не съм я тествал в реална среда, но не очаквам драми и на реална машина като му дойде времето.

  1. Създаваме същото оформление файловата система като на другите ни дискове – sfdisk -d /dev/sdb | sfdisk /dev/sdc
  2. Надграждаме настоящият ни масив на RAID5 – mdadm –grow /dev/md0 –level=5
  3. Добавяме новия диск към масива – mdadm –manage /dev/md0 –add /dev/sdc . Тука идва тънкия момент че масива все още продължава да си RAID1 и няма да започне се синхронизира понеже новия диск ни е spare
  4. Най важният момент sdc става активен и започва синхронизацията – mdadm –grow /dev/md0 –raid-devices=3 . Добър момент да си отворите бирата ако не е направено 😉 Не прекъсвайте процеса при никакъв случай!!!
  5. След като приключи синхронизацията остана да преоразмери дяла понеже загубата на пространство при RAID1 e 1/n а при RAID5 e 1-1/n

Най големият бонус е че не се налага рестартиране на системата или вадене и правене на допълнителни масиви.

sfdisk -d /dev/sdb | sfdisk /dev/sdc
mdadm --grow /dev/md0 --level=5
mdadm --manage /dev/md0 --add /dev/sdc
mdadm --grow /dev/md0 --raid-devices=3
resize2fs /dev/md0

Лека вечер 😛

Подготвяме нова услуга за хостинга и по време на тестовете при опит за свръзка между WHMCS и Cloudmin имахме следната грешка

CURL Error: 7 – couldn’t connect to host

 

Забавно веднага проверявам връзката между машините където е WHMCS-a и Cloudmin-а всичко работи. Проверявам 10000-ния порт и той отворен и достъп до него има 🙄 . Забавно!

Правя един бърз  на cloudmin сървъра


tcpdump -i br0 host WHMCS_IP

и за мое (не много голямо) изумление гледам че се опитва да се свърже на 80-ти или 443 (ако е активиран SSL) портове без да ме пита за такъв. По подразбиране webmin-a и cloudmin-a който е приложение към първия работят на SSL 10000 порт. Понеже тая глупава система е IonCube криптирана няма как да си едитна кода че да им оправя индииските глупости та се налага по радикален подход. Преди да напусне системата подменям порта на дестинацията с iptables


iptables -t nat -A OUTPUT -d cloudmin_ip -p tcp -m tcp --dport 443 -j DNAT --to-destination cloudmin_ip:10000

където заменяте cloudmin_ip с IP-то на вашата cloudmin инсталация. След тая дребна манипулация връзката между WHMCS и Cloudmin се осъществи, но модула продължава да има и други проблеми освен този 😆 :mrgreen:

В общи линии за година ползване на WHMCS съм крайно разочарован от него – доста е дървен, поддръжката на support екипа е бавна, документацията на кода и разни други неща се разминава с реалността, доста голямо количество бъгове и е доста дървен. Ако знаех че е толкова зле бих предпочел да го ползвам с нулиран лиценз вместо да се дадат 300$ за нещо което работи някак!

http://www.youtube.com/watch?v=GF2-TKfQOsk

2 бързи RAID 5 съвета

  1. Ако имате RAID 5 система дръжте дисковете в MBR вместо в GPT – поне при мен даде +10 – +15% разлика
  2. Задължително настройте /sys/block/md0/md/stripe_cache_size тъй като по подразбиране е твърде малък. Тука стойностите са според зависи при мен 32768 даде най приличен резултат

Когато правите RAID слоя над него го направете на LVM така ще си спестите много терзания ако сте задали не съвсем добре преценени размери на дяловете. Идеята е че ако не ползвате XFS или ZFS или някоя друга FS която позволява преоразмеряване на дяловете както EXT2/3/4 например нещата стават голяма кочина като осъзнаеш, че не си направил най- доброто делене. В общи линии получавате максимална пластичност ако е необходимо намаляне или увеличаване на размеря на дяла и същевременно сте подсигурени против неприятни случки на данните ви. В общи линии се получава нещо от този вид

| / | /var | /usr | /home  |
 --------------------------
|       LVM Volume         |
 --------------------------
|       RAID Volume        |
 --------------------------
| Disk 1 | Disk 2 | Disk 3 | 

От около 2 седмици php 5.3 влиза във историята бавно но сигурно. На 11-ти обявиха края на поддръжката му и че ще бъдат пускани само кръпки по сигурността в продължение на 1 година. В общи линии PHP 5.4 преминава в стадии old stable а PHP 5.5 става stable, което е малко забавно понеже все още част от допълненията и плъгините на php не работят съвсем коректно но пък и версия 5.5 е доста нова затова ще се въздържа от миграция към нея.

Та нека да си кажа за миграцията ми към 5.4 от 5.3. Предварително бях пуснал информация за остарелите функции, такива които са променени кардинално и такива които вече няма да се поддържат за да нямаме драми и от двете страни дали ще запали или не 😉 Та днес сутринта избрах час за старт на миграцията около 7 като стана, че да има минимални болки при миграцията ако не мине гладко. За моя огромна изненада всичко мина повече от гладко – компилирах си PHP 5.4.17 стартирах apache-то и о небеса всичко е там. Бърз поглед из логовете няма рев на depricated или въобще непознати функции – явно момчетата са си свършили работата добре. След това ми остана само да прекомпилирам и допълненията които са компилира със старото API като APC, RAR и прочие. Втори рестарт и всичко заспа. Отделно очаквам подобрения в производителността тъй като навсякъде хората сочат с големия пръст едни таблички дето се показва как PHP 5.4 консумира по малко РАМ и изпълнява скриптовете по бързо.