Migrado de RAID1 al RAID5 rezultis esti multfoje pli facila ol mi pensis 🙄 Ĝenerale ili estas 5 simplaj malgrandaj atendaj paŝoj kaj 1 biero por kuraĝo.

Por mi, la sistemo estis kreita RAIDO tabelo md0 en kiu ili partoprenas 2 sda kaj sdb-disko. Mi aldonos 3-an sdc al ili por krei RAID5 3 veturado. Ĝenerale, ĉi tiu akrobataĵo estas por la scienca celo de virtuala Mi ankoraŭ ne testis ĝin en reala medio, sed mi ne atendas dramojn pri vera maŝino kiam venos la tempo.

  1. Ni kreas la saman dosiersistemon kiel ĉe niaj aliaj diskoj – sfdisk -d / dev / sdb | sfdisk / dev / sdc
  2. Ni altgradigas nian nunan RAID5-tabelon – mdadm –kreski / dev / md0 –nivelo = 5
  3. Ni aldonas la novan diskon al la tabelo – mdadm –administri / dev / md0 –aldoni / dev / sdc . Jen la maldika punkto, ke la tabelo ankoraŭ estas RAID1 kaj ne komencos sincronigi ĉar nia nova stirado estas ŝparema
  4. La plej grava momento sdc fariĝas aktiva kaj sinkronigado komenciĝas – mdadm –kreski / dev / md0 –raid-aparatoj = 3 . Bonan tempon por malfermi vian bieron se ĝi ne plenumas 😉 Neniel ajn ne ĉesigu la procezon!!!
  5. Post kiam la sinkronigado finiĝis, lasis regrandigi la subdiskon ĉar la perdo de spaco en RAID1 estas 1 / n kaj en RAID5 estas 1-1 / n

La plej granda bonzo estas, ke ne necesas rekomenci la sistemon aŭ forigi kaj krei aldonajn tabelojn.

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

Bonan vesperon 😛

Ni preparas novan gastigan servon kaj dum la provoj provinte konekti inter WHMCS kaj Cloudmin ni havis la sekvan eraron

CURL-Eraro: 7 – ne povis ligi gastiganton

 

Amuze, mi tuj kontrolas la rilaton inter la maŝinoj, kie estas la WHMCS kaj Cloudmin, ĉio funkcias. Mi kontrolas la 10000-an havenon kaj ĝi estas malfermita kaj mi havas aliron al ĝi 🙄 . Amuzo!

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

tcpdump -i br0 host WHMCS_IP

kaj por la mia (ne tre granda) miro Mi vidas, ke provas konektiĝi al la 80-aj aŭ 443 (se SSL estas enŝaltita) havenoj sen peti min. Defaŭlte, retejo kaj cloudmin, kiu estas aplikaĵo por la unua, funkcias en SSL 10000 haveno. Ĉar ĉi tiu stulta sistemo estas IonCube ĉifrita, vi ne povas redakti vian kodon por ripari hindan sensencaĵon, do vi devas radikaliĝi.. Antaŭ ol forlasi la sistemon, mi anstataŭigas la cellokan havenon per iptables

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

kie vi anstataŭigas cloudmin_ip per la IP de via cloudmin-instalado. Post ĉi tiu malgranda manipulado, la rilato inter WHMCS kaj Cloudmin okazis, sed la modulo ankoraŭ havas aliajn problemojn krom ĉi tio 😆 :mrgreen:

Ĝenerale, dum unu jaro uzado de WHMCS mi estas ege seniluziigita pri ĝi – ĝi estas tute ligna, apoga teamo subteno malrapida, la dokumentado de la kodo kaj diversaj aliaj aferoj diferencas de la realo, sufiĉe multe da cimoj kaj estas sufiĉe ligna. Se mi scius, ke ĝi estas tiel malbona, mi preferus uzi ĝin kun rezerva permesilo anstataŭ doni 300$ por io, kio iel funkcias!

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

2 rapida RAIDO 5 konsilon

  1. Se vi havas RAID 5 sistemo konservu la diskojn en MBR anstataŭ en GPT – almenaŭ li donis ĝin al mi +10 – +15% diferenco
  2. Nepre agordi / sys / block / md0 / md / stripe_cache_size ĉar ĝi estas tro malgranda implicite. Ĉi tie la valoroj laŭ mi dependas 32768 donis la plej decan rezulton

Kiam vi faras la RAID-tavolon super ĝi, faru ĝin per LVM, do vi ŝparos multajn problemojn se vi agordas ne tre bone taksitajn dispartajn grandojn.. La ideo estas, ke se vi ne uzas XFS aŭ ZFS aŭ iun alian FS, kiu ebligas regrandigi dividadon kiel EXT2 / 3/4, ekzemple aferoj fariĝos granda ĝenaĵo kiam vi konscias, ke vi ne plej agis- bona divido. Ĝenerale vi ricevas maksimuman plasticecon se vi bezonas malpliigi aŭ pliigi la grandecon de la subdisko kaj samtempe vi estas protektita kontraŭ malagrablaj eventoj de viaj datumoj. Ĝenerale oni ricevas ion de ĉi tiu speco

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

De proksimume 2 semajnoj php 5.3 eniras historion malrapide sed certe. La 11an, ĝi anoncis la finon de sia subteno kaj ke nur sekurecaj diakiloj estos liberigitaj por 1 jaro. Ĝenerale, PHP 5.4 iras en malnovajn stabilajn stadiojn kaj PHP 5.5 fariĝas stabila, kio estas iom amuza ĉar iuj el la aldonaĵoj kaj kromaĵoj de php ankoraŭ ne funkcias sufiĉe ĝuste, sed ankaŭ versio 5.5 estas tute nova, do mi sindetenu de migri al ĝi.

Do lasu min sciigi vin pri mia migrado al 5.4 de 5.3. Mi estis liberiginta ĝin anticipe informoj por malaktualaj ecoj, tiuj, kiuj ŝanĝiĝis draste kaj tiuj, kiuj ne plu konserviĝos, por ke ni ne havu dramon ambaŭflanke ĉu ĝi ŝaltos aŭ ne 😉 Do hodiaŭ matene mi elektis la tempon komenci la migradon ĉirkaŭe 7 dum li ellitiĝis, ke estas minimuma doloro dum migrado se ĝi ne iras glate. Al mia granda surprizo, ĉio iris pli ol glate – Mi kompilis mian PHP 5.4.17 Mi komencis apache kaj ho ĉielo ĉio estas tie. Rapida rigardo tra la ŝtipoj tute ne bruas de malprudentaj aŭ nekonataj trajtoj – ŝajne la knaboj faris bonan laboron. Tiam mi nur devis kompili la komplementojn, kiuj estis kompilitaj kun la malnova API kiel APC, RAR kaj aliaj. Dua rekomenci kaj ĉio endormiĝis. Aparte, mi atendas rendimentajn plibonigojn ĉar ĉie homoj atentigas per dikfingro iujn tabelojn, kiuj montras kiel PHP 5.4 konsumas malpli da RAM kaj ekzekutas skriptojn pli rapide.