Dell R310 -> R450 upgrade rémálom

-

( zeller | 2023. 04. 22., szo – 17:59 )

"hogyan lehetne ezt elkerülni a jövőben" - Röviden: NEM egy darab vason tartani a kritikus szolgáltatásokat. Ez a történet ugyanis világosan mutatja, hogy katasztrófahelyzetben (szerver "eltűnik") valójában mi történik: minden megáll, BCP feliratú mappa elővesz, és aszerint korlátozottam működik a cég. nem, ez nem a nagyvállalati megoldás, ez a józan ész diktálta felállás... Az egy darab IP-cím/ethernet port az is egy erős korlát/SPOF, de az még áthidalható, bár akkor is lesz még (legalább) egy SPOF-od.

nalunk ilyenre proxmox 2 node cluster volt (linstor drbd datastore-al), ha egyiken karbantartas van, akkor futott minden a masikon. automata HA-ra nem volt szukseg, igy nem kellett egy 3-ik node a szavazashoz.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

igen, a monitoring szolt, hogy baj van/lesz. ezen nem volt db, ami volt az meg allhatott annyit hogy "eldontsuk" a lepest. ide-oda flappolasnak _jelen_ confignal nem volt ertelme. a levelezes kibirja ha all egy kicsit, a tobbi dolog is. nemkellett 99,9999999 sla. nemkell az agyu, ha csak verebre lovunk... :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hogyan csinálnád meg KKV szinten?

 

2 gép DRBD-vel (C protokoll), manuális failoverrel.

Ha a primary gép lehal, a másikon kiadod, hogy drbadm primary fontosdrbdparticio és az élet megy tovább.

Még egyszerűbb, ha a fontosdrbdpartíció egy VM image, így még szolgáltatásokat se kell külön elindítanod, csak magát a VM-et.

Egymás mellé tenném, patch kábel távolságra.

Ilyet 1Gb-es DRBD kapcsolatokon üzemeltetek, de nincs (sebesség) kritikus DB rajta, csak pár VM (KKV, file szerver, ERP, mail). Meg a szervernek sincs csak 1 Gb-es külső kapcsolata.

De lehetne pl. 2.5Gb-es hálókártyákkal, akár bondolva, port szám szerint load-balanceolva (így van esély, hogy több DRBD kapcsolat esetén, amik különböző portokon mennek, megoszlik majd a forgalom).

Szerk.: ha már Dell, 1-1 https://www.dell.com/en-ie/shop/dell-2nd-aqtion-5-25gbe-network-interfa… a 2 szerverbe, patch kábellel összedugva, és mehet rajta a replikáció. Persze ha a szevered 10Gb-es forgalmat szolgál ki, akkor már nem lesz jó (de az már szerintem nem KKV szint). 5 Gb-es replikáció az már bőven több, mint egy SATA/SAS diszk sebessége, az nem fog észrevehetően lassítani.

A db replikáció nem lassítja a folyamatot? (nem csináltam még)

Létezik a Galera cluster (ehhez már 3 gép kell, vagy 2+1 egy "csendestárs"), ami ugyanúgy szinkron DB replikáció, mint a DRBD-C, csak DB szinten, nem az alatta levő blokkeszköz szinten, az is működik, nem lassít vészesen (persze az se jó mindenhova).

Hogyan csinálnád meg KKV szinten?

Felhőben.

Nyilván a KKV nem költ annyit rá, mint amennyit kellene. Vagy nem tud, vagy nem akar. Tehát meg kell oldani olcsóbban. Ez mehet a minőség rovására, vagy történhet úgy, hogy a maintenance munkát olyanra bízod aki nagyüzemben sokkal olcsóbban csinálja. 

Ezt kifejthetnéd, mert ez így nem mond semmit. 

Mi az, hogy magának? A cloud szolgáltató karbantartja a saját infrastruktúráját, te pedig azt veszed igénybe. Te is használod, és te nem fizetsz extra hardverre és neked nem esik ki több napnyi elérésed annak köszönhetően, hogy ők ezt nulla downtime mellett megcsinálják.

Ez bullshit. Mondasz ilyet, hogy "sok esetben". Milyen viszonyítási alapon? Milyen mérésre alapozva? Milyen esetekben?

Nem azért használ AWS-t az internet kétharmada, köztük kis cégektől óriásokig, mert annyira nem érné meg nekik.

Persze ha egy AWS mellé egy redundanciát mellőző szervert állítasz, eltekintesz az extra karbantartás költségektől, és csak a teljesítményt nézed, akkor tényleg az AWS a drágább.

Bocs, beleszólok: A cloud nem csodaszer. Nem egy univerzális megmentő. És főleg nem olcsó minden esetben. Nem mindig kell csillagrombolóban gondolkodni.
A clouddal kitűnően lehet pénzt égetni az ellustult babzsákfejlesztők miatt. Bármennyire is mond hülyeségeket Hajbazer, de ebben a mondatban rengeteg igazság van.

Szerintem mindkét oldal túlegyszerűsíti a kérdést. A cloud nem olcsó/drága/jó/rossz. Ez egy eszköz. Vagy még az sem, csak egy szemlélet. Nem csak AWS van, Oregon nyugodtan építhetne saját cloudot. Azért nem épít/építtet, mert nincs rá szüksége.

Nemrég egy ismerősnek besegítettem, ahol egy kampányszerű tevékenysége miatt kellett neki egy faék egyszerű appot hostolni valahol. A megoldás havi <10 dollárba kerül Azure-ban: ACA + CosmosDB Serverless + Blob Storage. Persze mondhattam volna neki, hogy béreljen fizikai gépet valahol, és akkor legalább legközelebb nem tőlem kérne segítséget. :)

Értem én, hogy hol  a helye. Azzal nem értek egyet, ahogyan az átlag KKV használja. Bérel egy minimal VPS-t, felrakja az agyon pluginizált WP oldalt rá és boldog, mert olcsó. Ettől én hányok, nagyon pitinek tartom az egészet.

Vajon hány VPS tulajdonos-nak van titkosítva a a root particiója?

Ja, így már értem, de nulla hozzáértéssel nagyon nehéz nyerni, ebben nem a VPS lesz a szűk keresztmetszet.

Amúgy VPS != cloud, még csak a részhalmazának sem feltétlenül mondanám. De pontosítok, még a VPS sem lenne az ördögtől való, ha nem mindenki a legfilléreskedőbb megoldásokat választaná, az ügyfél és a szolgáltató is. Nyilván ez fordítva is igaz, ha AWS-ben csinálok 1 db VM-et, és arra telepítem fel ugyanazt a fostengert, azzal nem leszek előrébb, ebben igazad van.

Szerintem ez a 'cloud" szót jól elkoptatták a marketingesek, pedig valójában semmi ördöngösség nincs benne, egészen egzakt, 3-4 elemű definíciója van.  Én biztos nem tenném egy lapra az ötdolláros dzsunka-VPS-t a hiperkonvergens infra megoldásokkal, pedig cloud-cloud, nem? :)

Nem csak AWS van, Oregon nyugodtan építhetne saját cloudot. Azért nem épít/építtet, mert nincs rá szüksége.

Én pont nem erre gondoltam cloud alatt.

Cloud az is, ha ugyanazokat a VPS-eket ugyanazokkal a resource limitekkel az AWS-en vagy bárhol máshol futtatod.

A lényeg pont nem az, hogy az általad említett felhőben fusson a cucc amit akár Oregon is tudott volna sajátot építeni. Hiszen pont az a baj, hogy ha sajátot építesz ami ugyanúgy egy szerveren fut, ugyanúgy kieshet, ugyanúgy fenn kell tartani és maintainelni. 

A lényeg az, hogy rábízod egy szolgáltatóra pár extra dollárért hogy ezeket kezelje neked, cserébe te tudsz fókuszálni azokra a dolgokra, amik tényleg a te terméked szempontjából egyediek. 

Senki nem mondta, hogy a cloud csodaszer.

A cloudban eszközök vannak amik az üzemeltetési feldatok kis vagy nagy részét átveszik, hogy azzal ne neked kelljen vesződni.

Ez nem csillagrombolóban gondolkodás. Ugyanaz a VPS futhat egy házi szerveren és AWS-en, az utóbbi lesz stabilabb és megbízhatóbb. Az utóbbi esetében nem kell gondolkodnod vas bővítésen, karbantartáson és aggódnod a raid kártya konfigurációja miatt. 

Közben meg szoftver oldalon ugyanarról van szó. 

Most se pechem volt. Hülye voltam, mert vakon bíztam. 

Mi garantálja, hogy kedvenc felhős céged nem fog összeomlani?

Engem kikészítene az a tétlenség, amikor leáll egy aws félnapra és nem tudok semmit csinálni csak szurkolni nekik.  Annál még az ilyen crash-t is jobban kezelem.

Mi garantálja, hogy kedvenc felhős céged nem fog összeomlani?

SLA-k, óriási redundancia, stb. 

amikor leáll egy aws félnapra és nem tudok semmit csinálni 

Nem állítom, hogy AWS-en nincs szolgáltatáskiesés, de olyan nem igazán van, hogy az egész AWS áll fél napra. És ilyenkor is vannak eszközeid, pl másik régióban felhúzni a kieső részét az infrastruktúrádnak backupból, hogy addig onnan menjen. 

Értem, csak már azt nem tudom, hogy ez mivel lenne kevesebb munka nekem. Azt látom, hogy bevezetek vele egy újabb függőséget és egy újabb réteget.

Tudod nekem még a hello world is egy soros program kb bármely nyelven, és nem 200 mega a keretrendszer miatt. Stratégiailag nagyon veszélyesnek tartom amiket a cégek csinálnak. Pár cégtől fog függeni a világ szolgáltatásai. Annak idején az internet tervezésénél kifejezetten figyeltek a decentralizációra. Most meg, kb ez el lett felejtve. (Nem technikailag, inkább jogilag.)

Ühümm.... A jog annyit ér, amennyit be lehet belőle tartatni. Ha leáll az AWS, nem működik az általam igénybe vett cloud szolgáltatás, akkor nem tud vigasztalni az SLA, redundancia, esetleges kártérítés pár száz € erejéig.

A másik, hogy én úgy látom, hogy Oregon szeret irányítani, szereti, ha a kezében vannak a dolgok és nem mástól kell függenie. Ez néha jó, néha rossz tulajdonság. Ez a látásmód szerintem teljesen érthető, vannak ilyen embertípusok.

Így van. Az én életem, én akarok dönteni róla. Lúzereknek tartom azokat akik átadják a döntés a saját sorsukról másoknak. Nem mikromenedzser vagyok. Simán kiadom a munkát másoknak, de kontroll mellett. Még az sem fontos, hogy a kontrollt én gyakoroljam, lehet az egy delegáltam is. Az IT náluk más tészta. Ez a cégem versenyelőnye, és amiatt mert én csinálom. Még, ha szarul is teszem ezt.

Rendben, és szerinted melyiknek garantáltabb az uptime-ja? Egy darab szervergépnek, bekötve egy darab szolgáltatóhoz, vagy annak a redundanciának amit egy AWS ad?

Lehet jönni azzal, hogy a jog mennyit ér, a valóság viszont az, hogy a házilag barkácsolt dolgok mindig instabilabbak lesznek, és nem feltétlenül azért, mert házilag nem lehet jól megcsinálni, hanem mert rövid távon eljutsz oda, hogy stabilan működőnek látszik, és nem raksz bele több erőforrást, mert nem érné meg. 

Ez a látásmód szerintem teljesen érthető, vannak ilyen embertípusok.

Ezzel nincs baj, csak legyen értelme irányítani valamit. Van ami jó móka, és jó vele játszani, de nem térül meg.

Majd 25 év AWS tapasztalat után nézzük meg.

Amit nem veszel figyelembe az a stratégai döntések. Tudást kiadni, majd házon belül felszámolni katasztrofális döntés.
Azt beszélik, hogy: Docler eladta az üzemeltetést a ServerGarden-nek és állítólag a vételárat otthagyta a cégnél az első évben. 

Tudást kiadni, majd házon belül felszámolni katasztrofális döntés.

Attól függ van-e szükség arra tudásra. Nálad miért nem saját magad által buildelt linux disztró fut, és a hardvert miért veszed készen, miért nem saját magad építed? 

Vagy erre a tudásra már nincs szükség üzemeltetéshez? Persze, hogy nincs. 

Mindkét irány teljesen valid, csak el kell fogadni, hogy más jellegű problémákkal kell számolni, bármelyiket választod.

Amíg az egyiknél a munkaidő a kérdés, a másiknál az ilyen. Baromi tanulságos a sztori, de nemcsak azért, amit a cikk ír, hanem mert a megelőzés pofonegyszerű lett volna, csak az ábra szerint a többség nem foglalkozott vele.

Na igen, és ilyenkor derül ki, hogy ki árazta be helyesen a kockázatot. Valaki letolt gatyával várta, hogy mi lesz*, valakinek meg fel sem tűnt, mert a lokális registry cache-ből ugyanúgy működött minden tovább, amíg az upstream meg nem oldotta a problémát.

(* Nyilván egy ~10 soros "library" hiányát relatív gyorsan meg lehet oldani, de left-pad helyett éppenséggel mehetett volna a levesbe valami komolyabb is.)

( Nyosigomboc v | 2023. 04. 22., szo – 19:56 )

Amiket biztosan maskepp kellett volna:
-Tudom, hogy draga a szabadidod, de nem veletlenul szoktak a rizikosabb dolgokat hetvegere utemezni. Keddtol pentekig lefutott volna par hardware teszt, es mas, ha hetvegen all 30 orat a rendszer, meg mas, ha a het kozepen (a termelessel egyutt).
-Igen, a HW raid-nek pont az a hatranya, amit irtal. Nem tudom, mi a rendszered terhelese, ez ritkan szuk keresztmetszet. (regen inkabb az volt)
-A virtualis gepnek, kontenernek az az egyik elonye, hogy barmin elfut. Amig az eles rendszeredet allitgatod, mehet a regi (backup) serverrol, extrem esetben laptoprol/desktop geprol is.
-Atallast celszeru backuppal kezdeni. Ha sikeresen lefut, legfeljebb torlod (de akkor is jo, ha ott a friss mentes), ha sikertelen, akkor meg lehet mire visszaallni.

De nem ertek hozza, inkabb fejleszto vagyok.

A strange game. The only winning move is not to play. How about a nice game of chess?

Tudom, hogyha pénteken műszak után kezdek hozzá, akkor senkinek nem hiányzik a szerver, az ügyfeleknek sem. Ugye ez is egy 5 perces melónak indult. :)

Értelmesen elköltött pénzt szívesen szánok rá (ez a gép is 2 milla volt). Ha venni kell még egyet és berakni egy másik szolgáltatóhoz, az emészthető nekem. Lehet nem ez a legjobb megoldás. Lehet minimal vps-ekből kellene valamit felépítenem, amelyek különböző szolgáltatónál vannak és ezt is csak backupnak.

Jelenleg itt tartok ahol a poszt, és most kell gondolkodnom rajta, amíg friss az emlék. Mivel amúgy valószínűleg a következő 10 évben rá sem kell néznem a gépre, emiatt kevésbé leszek a jövőben motivált.

"ez is egy 5 perces melónak indult" - Nincs öt perces meló. Illetve van, de a diszkek körül kicserélni a szervert az pont nem ilyen. Egy szolgáltatás leáll/backup/szerver leáll/kiszerelés/beszerelés/boot/teszt/szükség esetén rollback soha nem öt perc. Ilyenre első blikkre legalább(!) 4 órás időablakot mondanék, és részletes(!) visszaállási terv nélkül egy lépést se.

"a következő 10 évben rá sem kell néznem a gépre" - Firmware frissítések, OS-frissítés, hw-hiba mind "ránézős" feladat. Ezen felül egy 5+ éves (nulla garanciával/supportal rendelkező) vason kritikus szolgáltatást hagyni erősen orosz rulett...

Semmi gond. Ezért is érdemes lehet a hosting szolgáltató SMTP szerverét beállítani vagy valamilyen tőled teljesen független SMTP szervert az iDRAC riasztásokra.

Beállíthatsz több email címet is.
Másrészt fogsz egy RPi-t, ami az otthoni neteden lóg és pingeti mondjuk percenként a szervered. Ha kiesik mondjuk 5 ping, akkor meg küldj az RPi neked levelet vagy push notificationt a mobilodra. Persze ezt is össze lehet rakni cloudban.

( quash | 2023. 04. 22., szo – 20:30 )

Ha mentesülni szeretnél a jövőben az ilyenektől, és csak egy hostingban lévő HW-re van keret.
    • A hosting hardware-en csak egy számodra elfogadható, kezelhető, ismert hypervisor fusson.
Ez alatt nyugodtan lehet HW RAID, gyorsabb, jobb, etc …
    • Minden amit ki akartok szolgálni, VM-ben fusson
    • A VM-ekről legyen legalább napi mentés, local, remote.

Legközelebb ha HW csere van:
    • HW csere előtt, az összes VM leállít, különbözeti mentés indít, így lesz minden fontos cuccról mentésed, leállított állapotban.
Illetve csinálj Hypervisior configokról egy mentés, pl. linux esetén kb. /etc.
    • Új HW beállít, ha kiderül hogy pl. jelen esetben nem sikerült a RAID migráció.
Akkor fogod a hypervisor-t kb. max 20p alatt feltelepíted
      A VM-eket a backupból beimportálod, és kb. meg is vagy!

Mivel lehet ezt kényelmesen, (olcsón) megcsinálni?:
    • host-ra felraksz egy proxmox-ot
    • adsz neki local-ban egy lemezt, dedikált backup-ra.
    • Ha van rá keret, irodában, etc … csináltok egy remote backupot.
Erre akár egy synology NAS is jó lehet, de még jobb pl. egy Proxmox Backup Server
    • Értelem szerűen, nem csak a VM-eket, hanem host-on legalább /etc-t napi szinten 1x mented.
    • Proxmox telepítése kb. 10p, konfigurálása kb. újabb 10p.
Innen már csak ilyen esetben vissza kell húzni a VM-eket, ez pedig VM méret, és backup SRC disk/network speed kérdése

( n.balazs v | 2023. 04. 22., szo – 20:54 )

Ez a történet egy igazi állatorvosi ló. Kezdőknek és haladóknak is. Bocsánat, hosszú leszek.

Meglátásaim - nem kioktatásnak szánom, inkább olyan összefoglalónak:
- Nagy szerencséd, hogy tiéd a cég. Különben a tulaj a fenti munkavégzésért minimum a szőnyeg szélére állított volna. Rosszabb esetben kártérítést kellett volna neki fizetned.
- Óriási kockázat vagy a saját cégedben. Tudom, ezt sok ember nehezen fogadja el pszichológiailag.
- Nem volt rollback planed. Semmilyen. Ami volt, az meg használhatatlan volt.
- R310 -> R450 között elég nagy az ugrás RAID vezérlők terén is. Egy R310->R320 esetén elfogadható lenne ez a lemez átrakás + RAID tömb import (egyébként a rollback miatt ott is hibás megoldás!), de ekkora ugrásnál nem csinálunk ilyet. Soha! Halálfejes hiba!
- "Áááá, csak egy 5 perces munka lesz" típusú feladatokból szoktak jönni a nagy összeomlások, pislogások.
- SOHA nem jössz el úgy a szerverteremből, hogy "ááá, maradt még egy kis hiba, majd megoldom távolról". Nagy az esélye, hogy nem fog távolról menni és felülsz a "rácsesztem" vonatra.
- Kaja és alvás. Ezek szent dolgok, nagyon fontosak az ilyen átállás előtt és közben is. Éhen, fáradtan tuti rossz döntéseket hozol, többször hibázol. A kaja még ihletet is adhat - van módod, időd átgondolni, hogy hol tartasz, hogyan lehetne továbblépni.

Azzal se jöjjön senki, hogy bízzam szakemberre, mert ismerem a szakembereket.

Nem. Nem ismered a JÓ szakembereket. Egy jó szakembernek, ha elmondod, hogy mit akarsz csinálni és hogyan, akkor piros tollal áthúzta volna az egészet. Majd elmondta volna a buktatókat. Egy még JOBB szakember meg letett volna eléd egy olyan tervet, amiben kevesebb a kockázat és még működik is.

Aki jó, az erre a szintre le sem hajol. Aki lehajol, az lehet nekem kevés, mert ha guru is, egyszemélyes EV, aki önmagában kockázat nekünk.

Tévedés. Lehajol, ha látszik, hogy tud veled együtt dolgozni és nem egy balfasz tulajdonossal van dolga, aki mindent jobban akar tudni - találkoztam mindkét típussal már.
Továbbá kikérem az egyszemélyes EV-k nevében a dolgot. Nem attól lesz valami kockázat, hogy 1 személy van mögötte vagy 100. Láttam már utóbbival is beborulni rendszereket, ahol mindenki csak pingvinezett ("nem az ő dolga", "oldja meg a xy team"). Aztán jött az 1 személyes hős, aki kiganézta a rendszert, hogy senki hátsója ne fájjon utána.
 

Hogy kicsit szakmai részt is tegyek hozzá: A jövőben a következő dolgokat javaslom számodra megfontolásul:
- Minden változás előtt csinálj egy részletes tervet. A tervnek legyen része a rollback plan is. Ennek célja, hogy a rendszer működése könnyen, gyorsan és egyértelműen visszaállítható legyen az EREDETI ÁLLAPOTBA. Itt az eredeti állapot az lett volna, hogy a lemezeket benne hagyod az R310-ben és a rendszert visszaállítod úgy, hogy arról fusson. Az R310 lemezeihez, a rajtuk lévő adatokhoz nem szabadott volna nyúlnod.
- A részletes terv mindig legyen leírva. Így ha elüt a 4-6-s villamos, akkor is valaki tudja folytatni az üzletet, vissza tudja állítani a céges IT-t működőre.
- Soha ne csinálj egy ilyen nagy átállást egyedül. Legyen ott egy másik szakember is, aki besegíthet, véleményt mond, irányt mutat.
- Én a helyedben már mindenképp elmentem volna virtualizáció vagy konténerizáció irányába. Azaz úgy kell tudnod szerver hardvert cserélni (akár komplett szervert is), hogy az minimális kieséssel járjon, ne kelljen konfig fájlokat túrkálni, kernel modulokkal szórakozni.
- Ha van egy kis pénzed, akkor Vmware, HyperV, Proxmox, Xen stb. alapokon nem nehéz összerakni egy olyan rendszert, hogy minden üzleti szolgáltatás csak virtuális gépeken BELÜL létezik. Egy tervezett kiesés esetén pedig a vm-eket lehet mozgatni a node-ok között. Akár menetközben is cserélheted az egyik node-t kompletten, sem kieséssel, sem kockázattal nem jár - feltételezve, hogy van elég node-od és redundanciád.
- Ezt a change-t úgy kellett volna kezdeni, hogy MENTÉS AZ ADATOKRÓL. Gond esetén pedig van egy friss mentésed, amire vissza tudsz állni. RPO 0 lesz, RTO lehet magas (pár óra).
- Nem kell itt nagy enterprise megoldásban gondolkodni (3-5 node, 2 storage, 2 datacenter stb.). Meg lehet ezt oldani KKV szinten is olcsón - mondjuk 5-10 misiből maximum. De lehet, hogy sokat mondtam ezzel az összeggel.

A részletes terv mindig legyen leírva. Így ha elüt a 4-6-s villamos, akkor is valaki tudja folytatni az üzletet, vissza tudja állítani a céges IT-t működőre.

Csak leírni a tervet olyan, mint a backup stratégia, ahol sosem próbálják el a visszaállítást.

Írd le, aztán ültess le valaki teljesen laikust, hogy csinálja meg. Utána a tapasztalatok alapján írd meg újra. :)

Amikor dokumentációkat kellett írnom, akkor alapvetően 2 fő lépésből állt nálam a leírás:
1. Végiggondolni és leírni magát a dokumentációt.
2. Validálni a dokumentációt akár egy kollégával, akár saját magam. Egy telepítési doksinál akár külön rendszert - DOC - építeni a DEV, TEST, STAGE, PROD stb. rendszerek mellé.

Ahol eddig dokumentálással találkoztam, ott a validációt szinte mindig kihagyták. Az emberek nagy része nem is érti, hogy miért kell validálni, hiszen "az jó, le lett írva, az úgy működik". Általában ilyenkor derül ki, hogy bizonyos dolog kimaradtak, rossz sorrendben vannak, szájbarágósabban kellene leírni ezt-azt.

A legnehezebb, ha a saját munkám kell validálnom. Olyankor át kell mennem "hülyébe, aki semmit se tud, L0 szintre" és úgy kell végigmennem a lépéseken. Kell egy kis idő, amíg átváltok a 2 üzemmód között fejben.

( uid_17626 | 2023. 04. 22., szo – 21:03 )

Köszi az eddigi jó tanácsokat. Igazából nem rossz alternatíva a még egy szerver, ami rossz benne, hogy azonos helyen van. Ebben leginkább a jogi problémát látom, ha az adott szolgáltató csődbe megy. Megjegyzem én már jártam így, lefoglalták a szerverem, mert azt hitték a hoszting cég tulajdona.

Erre is van megoldás: legyen egy napi szintű mentésed, amit nem a hosting cégnél tárolsz, hanem mondjuk otthon vagy a cég egyik székhelyén vagy egy másik hosting szolgáltatónál - akár cloudban is. Persze ez a mentés titkosított legyen.

Csak végig kell számolni és gondolni, hogy ebből mennyi idő alatt tudod felállítani a céges IT-t.
Én nem vetném el ilyenkor a felhős irányt se. Mentés az egyik cloud szolgáltatóhoz, automatizálni a vm-k telepítését (Azure: ARM template például, Ansible; AWS: Terraform), majd restore. Eleve kicsi az esélye, hogy erre át kell állnod és csak a storage díját fizetnéd havidíjként a cloud providernek. Átállás esetén persze ketyeg a vm-k díja, a kimenő internet forgalom díja stb.

De megteheted úgy is, hogy veszel egy 3. szervert, ami otthoni hidegtartalék, a mentés meg egy otthoni NAS-on ketyeg. Gond esetén beviszed egy hosting szolgáltatóhoz az adatok felmásolása után.

Min átlag három ilyen mentésem van. Hajnalban készül a szerveren egy napi snapshot, és abból megvan az utolsó két hét. Ezt húzza le két telephelyi szerver és minden  saját gépem, amikor azok online vannak.

Ha csak annyi lett volna, hogy ezek a snapshotok műszak végén készülnek el (és nem hajnalban), akkor ott a helyszínen reinstallal kezdhettem volna (1 órányi tranzakció vesztés lazán reprodukálható, még emlékből is). Persze ekkor is érdekelt volna maga hiba és annak az elhárítása, vagyis baszódtam volna vele egy darabig.

A két telephelyi szervert üzembe helyezni, mint helyettesítő szerver, pár tíz perc, de legyen max 1 óra. Onnan visszaállni az eredetire, már inkább hétvégi projekt, mert nincs automatizálva. Jelenlegi küzdelmem az elmúlt 8 óra adataiért ment. Az mindenképpen jó érzés, hogy nulla adatvesztéssel megúsztam (dns-t manual pótoltam). Magába az üzletbe nem tragédia egy félnapos kiesés. Soha nem volt az elmúlt 25 évben 10 percnél hosszabb kiesés. Az adatvesztés, már inkább az volna. Utoljára ilyen velem a kilencvenes években volt.

Szóval hiába csinálom ezt ezer éve, a kevés hw és tapasztalatszerzési lehetőség miatt, soha nem leszek senior a témában. Amit írtam, hogy nem bíznám másra, az tapasztalat. Ha csak az egyetemet végzett hallgatótársaimat nézem, a fele azt sem tudta volna mit tegyen, a másik fele elvitte volna a Kürtbe a device-t és 2 hét múlva lett volna szerverük. Nagyon kevés olyan ember van, akinek van töke beleállni egy ilyenbe és kockáztatni, hogy még nagyobb szar lesz. Valamint agya arra, hogy a stresszes feladat végzése közben párhuzamosan több megoldást tervezzen fejbe. Személyes egy ilyet ismerek, ő segített nekem, egy itteni fórumtárs. 

Félig offtopic:
Amikről itt a HUP-on beszélgetünk IT üzemeltetés címszóval, az többnyire már nem egyetemi tananyag. Inkább rutin+évek, megszórva egy kis józan paraszti ésszel, amire rájön az IT stressz kezelése is. Véleményem szerint ezek nem tanulhatóak, ha nincs meg valakiben az alapkészség hozzá.

Én is kevés embert ismerek, aki egy IT üzemeltetési stresszhelyzetben higgadtan, átgondoltan, logikusan tud gondolkodni és a helyzetet kezelni. Egyetemről egyet se. Exmunkahelyekről, projektekből, munkahelyről is csak 2-3 embert. Összesen.

Ennel viszont lenyegesen tobb olyan van, aki alapbol ugy all neki, hogy ne is lehessen adatvesztes (meg ilyen merteku leallas a het kozepen). Szerintem az egy jobb modszer, ha nem is hozod magad olyan helyzetbe, amibol mar nem lehet jol kijonni.

A strange game. The only winning move is not to play. How about a nice game of chess?

Valamilyen külső helyszínre lehet csinálni ilyen "eventually consistent" replikációt elég sokmindennel, DRBD is tud ilyet, a mysql master-slave replikációja mindig is ilyen volt, stb., ami azt jelenti, hogy ha nem is mindig a legújabb adatok vannak meg, azért nincs nagy lemaradás.

( Nyosigomboc v | 2023. 04. 22., szo – 22:55 )

Ha van kedved otletelni, irnal par dolgot a rendszerrol? Mi van rajta, mire hasznalod, meret/eroforrasigenye mi?

Ugy emlekszem, sajat kezuleg fejlesztett LAMP alapu weboldal (ugyfelkezelo/vallalatiranyitasi rendszer). Vagy Postgresql van alatta? (ez nagyon jol kezeli a master-slave modot 12+ eve)

Mi foglal ennyi helyet, ami miatt lassu volt a masolas? Gondolom nem a PHP-s rendszered. Levelezes? File serverkent is ez megy? (gondolom nem az adat 90%-a volt a backup)

Ha a termeles is allt (szoval az alkalmazottaknak nem mondhattad, hogy akkor 2 napig termeljek ugyanazt, amire a gepek be vannak allitva), gondolom a termelest is valamilyen szinten ez vezerli. Ez viszont azt jelentene, hogy ha a geped hostingban van, es a telepen elmegy a net, akkor megint baj lesz.

A strange game. The only winning move is not to play. How about a nice game of chess?

> Ha van kedved otletelni, irnal par dolgot a rendszerrol? Mi van rajta, mire hasznalod, meret/eroforrasigenye mi?

Expó tér:

2 db sas hdd raid 1 -> pv -> vg  = hdds
2 db sas ssd raid 1 -> pv -> vg = sdds

Host Kubuntu, szolgáltatások:
- nginx proxy és stream proxy
- ssh 
- GIT (origin) repo

Jelenleg 5 vps van rajta:
1 - céges LAMP lv <- sdds
2 - privát LAMP lv <- sdds
3 - mail szerver lv <- hdds (Postfix, dovecot, roundcube, sql auth, amavis, clamav, spamassasin)
4 - Win11 (majd a könyvelésének - internet korlátozással) lv <- sdds
5 - Win11 (nekem - internet korlátozás nélkül) lv <- sdds

Iroda és Telephely:
2 szerver megy, mindkettő ugyanazt csinálja (backup) az egyik egyben router/firewall is, a másikat fejlesztésre is használom.
Natív telepítések, LAMP.

Ezenkívül kb >220 db kliens eszköz, mint:
Dahua kamerák,
Dahua NVR-ek,
Mikrotik eszközök (ma már használhatnám ezt is, az egyik szerveren releváns funkciója helyett)
Kubuntu kliensek,
Tabletek (falra szerelve kb KIOSK helyett),
TV-k (falra szerelve információs panelek helyett) amiken böngészőben fut az ERP,
Telefonok, nyomtatók
 

> Ugy emlekszem, sajat kezuleg fejlesztett LAMP alapu weboldal (ugyfelkezelo/vallalatiranyitasi rendszer). Vagy Postgresql van alatta? (ez nagyon jol kezeli a master-slave modot 12+ eve)
mariadb van alatta jelenleg

> Mi foglal ennyi helyet, ami miatt lassu volt a masolas? Gondolom nem a PHP-s rendszered. Levelezes? File serverkent is ez megy? (gondolom nem az adat 90%-a volt a backup)
Fájlmellékletek. Adatok. Levelezésben megvan az elmúlt 20 év termése. Postfixben be volt kapcsolva az always_bcc is egy archiv user részére. A backup kb 65% volt, ebben benne van a lokális backup ás msáhonnan származó is.
2003 szeptemberében csinálta az ERP az első számlát, ezt ma is megnyitható, mint minden állomány.

> Ha a termeles is allt (szoval az alkalmazottaknak nem mondhattad, hogy akkor 2 napig termeljek ugyanazt, amire a gepek be vannak allitva), gondolom a termelest is valamilyen szinten ez vezerli.
Nem, mert ez túltermelést eredményezne, ami raktározási problémát okoz, valamint a szavatossági idő esetenként kockázat.

> Ez viszont azt jelentene, hogy ha a geped hostingban van, es a telepen elmegy a net, akkor megint baj lesz.
Ez nem baj, mert mindenkinek van mobil nete. Pár 1-2 órás kiesés nem számít, mert lehet addig mást is csinálni.

Git gondolom nem nagy, esetleg az egyseges backup miatt ez is mehet VM-be, bar lehet, hogy macerasabb, mint amit nyersz rajta.

A jelenlegi VM-ek kozul 1-est latom kritikusnak, esetleg 3-ast. Ha a konyveles 1-2 napig nem megy, az mas, mint ha a ceg. "Jatszos" VM-ek szinten.

Kliensek, rogzitok azt hiszem a servertol fuggetlenek annyira. Itt a backup lenyeges? A klienseken gondolom nincs kulon adat, csak a servert hasznaljak. A rogzito meg teljesen mas mufaj (jogilag is, meddig tarthatod, stb..), gondolom ott fix mereten tul amugy sem log. Az eszkozok mennyisegenel a cimtartomany meretere gondolom figyeltel (egyetlen C osztalyu 192.168.x.y tartomanyba nem fer bele hamarosan).

MariaDB master-slave-et meg kene nezni mennyire mukodik. PG-nel tud olyat, hogy a tranzakcio logot athozza a slave-re, szoval minden mindig replikalva van (ill. selecteket ki tud tenni a slave-re, es akkor nem a mastert terheli). Gondolom a Maria is tudhat hasonlot. (a visszaallas kicsit trukkosebb)

Az, hogy az elmult 20 ev minden adata elerheto ugyanugy egy helyen, kenyelmes. Ha nem kell kerulgetni, nincs is baj vele. Az elonyeit-hatranyait ismered. Ha mozgatni kell, annyival tobb adatot jelent. (lehet vegyesen pl. olyat is, hogy pl. az ERP adatai ott vannak, a levelek/mellekletek meg archivumban)

A raktarozasra nem gondoltam, jobban ismered a sajat cegedet. :) Az viszont nem jo, hogy nincs elore ott n db. (vagy adott idore szolo) task, hogy a kovetkezo 2 napban mit kell termelni. Jo, valtozhat, ha bejon nagyobb prioritasu megrendeles, de gondolom az alapanyag miatt is fontos, hogy elore lehessen tudni valamennyire a termelendoket. Most jol jott ki, COVID idejen baj lett volna 2 nap kieses. Szavatossagi ido nagysagrendileg mennyi szokott lenni? Ugy emlekszem, nem tejuzemed van, hanem tisztitoszeres, de biztos van kimutatasod errol is, hogy mennyi raktarozas utan kelnek el a termekeid.

Net elmehet a hostingban is, bar nyilvan meg fognak tenni mindent, hogy ne menjen. Ha helyben is elerheto ami kell, akkor persze nincs baj.

Osszessegeben ugy tunik, jol osszeraktad a dolgokat.

A strange game. The only winning move is not to play. How about a nice game of chess?

GIT az kényelem, mondjuk az ssh-n keresztül -J-vel belső szerverre jumpolva még nem próbáltam.

Valóban 1-es és 3-as a kritikus. Hármas azért kell, hogy kapjon visszajelzést a felhasználó a rendeléséről amit weben küld be.

Kliensek kb lehetnének TV-ken lévő böngészők is. Nagy ritkán kell egy-egy office doksit szerkeszteni, de az is a szerkesztés után bekerül az ERP-be. Nincs is backup emiatt a klienseknél. Mondjuk nemrégiben fedeztem fel a laborban egy kis shadow it-t. Ottlévő a kolléga saját külső ssd-re dolgozik, hogy otthon tudja folytatni. A gépen nincs semmi. Bahh.

A levelezésre most azt találtam ki, hogy folyamatos rsync-es backup-ot fogok csinálni egy telephelyi meleg tartalékra. Így a következő katasztrófánál, kizárólag a db-kel kell foglalkoznom vagy azzal sem.

Az kifejezetten jó, hogy nincs n-db task a kollégáknál. Mindig csak a következőt látják. Az okozná a káoszt és nem lenne rollback. Jelenleg realtime tudjuk áttervezni a termelést. Ez hatalmas versenyelőny, de ilyenkor meg katasztrófa. 

Net elmehet a hosztingban: max csökken a sávszél, az Expó téri Docler-nél ez jól megvan oldva.

 

Köszi.

( ncc1701 | 2023. 04. 23., v – 20:32 )

Én fizikai vast már nem toszogatnék. Bérelni kell a vps szolgáltatásokat, és kalap.

Az komoly, jó áron adják, ez tény. Nem akarok negatív reklámot, úgyfél járt így x3-al. Ráadásul egy max 100w-os fogyasztó pici gépről volt szó.

Viszont rájöttél, amire anno én is, h jók ezek a raid vezérlők, de én úgy vagyok velük, mint az elefántokkal, szivesen elnézegetem őket, de otthonra nem kellene. Sw raid linux alatt elég pipec, bármibe berakom, amin van mdadm csomag, és működni fog.

Régóta tudom, hogy a hw raid a legnagyobb kockázat a rendszerben. Bármilyen probléma esetén akár több napba / hétbe telhet a megoldás.

Ahogyan az SW fejlesztésben is függetlenek akarunk lenni az implementációtól, úgy a hw-ben is ez a célszerű. Annak ma már örülök, hogy ez megvalósult, de ettől még ez egy szar hét volt. :)

Végig átéreztem a szívást olvasás közben. :) De ezekből tanul igazán az ember, én már nem vállalok be semmiféle rizikót. Mi csütörtök-pénteken már semmi nagyobb műveletet nem csinálunk, ügyfeleknél hétvégén van pörgés, nem akarunk kib@szni sem velük, sem magunkkal.

nyilvan ahol van 2 lemez, es egy mirrorba kell rakni, arra teljesen jo lehet az mdadm. a moka akkor kovetkezik amikor nem csak ennyi van: pl 8+ disk, raid5..6. kezdve ott hogy nincs is az alaplapon annyi sata port. aztan jol meg is kell nezni hogy az a sata portok hogy kapcsolodnak a cpuhoz (kozvetlen, "eszaki+deli hid", stb). es akkor a cache ram/flash+bbu-rol meg nem is beszeltunk.

btw, regen olvastam hogy az mdadm is kezel bizonyos hwraidban osszerakott diskeket: ha befosott a kartya, akkor mdadm is ossze tudja kaparni rajta az adatokat masik gepben.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Aki nagyvállalati/enterprise környzetben "élnek", annál a nagyon nem reprezentatív szavazásnál/topicban is khm. a hw-raid mellé tették le a voksukat. Amíg egy mdraid vagy lvm-es tükör esetén a rendszergazdának kell bacogatni a az OS-t, hogy döglött diszk ki, jó diszk vissza, miközben a normális hw raid esetén bezavarom a lótifuti operátort a gépterembe, hogy a döglött diszket húzza ki, és a kezébe adott újat tegye vissza a helyére, és a többit automatice elintézi a hw, addig... Szóval nem biztos, hogy sw raid mellé teszem le a voksomat néhány szekrényt kitevő szerverpark esetén... És egy-két gép esetén sem biztos...

Régi sztori, szintén operátor beküldős... Menjen be az x zónába, és jobb oldalon az n. rackszekrényben a memcached feliratú gépet indítsa újra. Nomostan másik irányból ment be... És a másik sorban onnan nézve az n. szekrényben volt memcached feliratú gép... (Tanulság sok volt - le lettek vonva anno, de a leállás/megborulás az sajnos megtörtént... )

Én  ilyen megaraid vezérlős gépekre százas nagyságrendben látok rá, nem igazán van velük gond. Nagios szól, ha kiesett egy diszk, vagy megdöglött a backup battery.

Persze ha csak egy gép van összesen, az valóban kockázat. De maga az egy gép a legnagyobb kockázat.

Azért 1 helyett 2 gép még nem nagyvállalat :)

Pont egy KKV-ban azután lett 2 szerver, miután egy desktop gépből kellett ideiglenesen főszervert csinálnom, az oldalán kilógatott winyókkal, amire az adatokat backupból szedtem össze, miután az egyetlen IBM gép alaplapja behalt és azon volt a RAID vezérlő is. Ráadásul a szervízes se volt a helyzet magaslatán, addig cserélgette az alaplapokat, amíg a raid tömb is megsemmisült.

Kell backup is nyilván, de azért nem árt, ha van egy olyan gép, ami minimális beavatkozással ott tudja folytatni, ahol az elsődleges megállt. Szerintem legalábbis. Meg azért nálad is a backupból visszaállás okozhatja 1 napi munka elvesztését, ezen is lehetne kicsit javítani.

Nem józsikabt-től kell bérelni a VPS-t, hanem fizetni valamelyik nagy szolgáltatónak, és nyilván az is egy szakma, hogy értsd hogy konfiguráld be az AWS-t. 

De nehogy már az legyen a nevetség tárgya, amiről a fél világ üzemel és számos nagy szolgáltató használja milliós userbázis kiszolgálására.

( p2pking | 2023. 04. 23., v – 20:38 )

Naice. Ez megjobb, ha egy atlagosan 40k userrel dolgozo oracle alatt kovet el a team hasonlot. Pentek ejszaka. Igaz hetfon 12 orara mar ment minden. RCA szep volt. Meg is dicsertek a teamet ev vegen. Akkor megtanulod, hogy tesztelhetsz, meg elokeszithetsz mindent akkor is a sorsnak van egy kulonosen ironikus humora. Legalabb tanitottunk valamit az IBM nek is.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

( tompos v | 2023. 04. 24., h – 22:01 )

Vhol mintha írták volna, azért leírom, ha mégsem, az első gyakorlati hiba az volt, h nem mentéssel kezdted IMO.

Ha olyan a rendszered, ami biztosítja a fájdalommentes, azaz gyors és egyszerű recovery-t, akkor bátran állsz neki a kockázatos lépéseknek is. Emellett sűrűbben tolsz rendszeres backupot (tipikusan ilyenek a block szintű backup megoldások, pl. zfs v. btrfs alapon v. asszem talan a restic, borg és a burp is tud rá kielégítőt nyújtani, az utóbbiakat nem használtam erre).

Ahogy más írta, nem bolt megfelelő BCP megoldásod, amikor éles helyzet volt, nemmazt választottad (ha jól értem). A második gép erre megoldás lehet, én azért lehet, h más irányból közeliteném meg. Nézd meg, h mennyibe kerul bérelni gépet a hostinngal együtt (pl. Rackforest) és mit nyersz v. vesztesz vele. Elnézve messze többet nyersz a bérelt megoldással, mintha tovább bonyolítasz egy rendszert, amihez amúgy sem értesz igazán (és szerintem eléggé). Összességében a rendszer megbízhatósága jobb lesz, mert kisebb a lehetőség a hibazásra.

 

Azzal nem értek egyet, h a megfelelő cégek nem nyúlnak le ennyiért. Persze nyilván meg kell fizetni, de tco-ban a kockázatokat is figyelembe véve jobban jössz ki.

Vedd ezt egy olcsó figyelmeztetésnek, csinálj egy *őszinte* risk assesmentet és az alapján értékeld, mi mennyit ér. Reálisan viszonylag magas probability mellett (mivel már előfordult ilyen eset, muszáj magasat adnod), magas az impact is (áll a business) egy hasonlo eset kapcsán. A kérdés, hogyan tudod csökkenteni a kockázatot.

Megoldhatod egy egyszemélyes hadsereggel is jól úgy, h csökkentitek a kockázatokat dokumentációval és automatizációval, betanítással. Valójában most is ez van, csak olyan csinálja, aki nem ért hozzá megfelelő mélységben (gyakorlati tapasztalat hiánya).

Ez volt 25 év után az első ilyen leállásom, ami nem tervezett volt, és 10 percnél tovább tartott. Adatvesztésem soha nem volt. Most sem. Mentésem volt, de nem real time. Nagyot hibáztam most, de messze nem katasztrofálisat. Annak a közelében sem voltam.

Vagy rosszul értékelném a helyzetem?

Az attól függ, a tűz közelében te vagy kizárólag, így te tudod megítélni.

 

Ha helyes az értelmezésem, akkor a gyar működésének kritikus, h menjen a szolgáltatás és kritikus, h folyamatosan meglegyenek az adatok.

Ezen kívül az OS-hez korlátozottan értesz (grafikus mankóra van szükséged) és a HW kezelés sem rutinszerű (LED, csavar rossz helyen).

 

Az, h csak ekkora gebasz lett belőle, szerintem a vakszerencse kérdése volt egy jó részt). Meg persze hoztál jó döntéseket is (backupot gyártottál, mielőtt tovább rontod a helyzetet), bár az inkább csak azt mutatja, h van józan eszed, nem vagy teljesen tapasztalatlan, mondjuk mid level.

 

Egy szerveres, hasonló környezetben magas uptime-ot a manapság már egészen jó eséllyel össze lehet hozni, megbízhatóak a HW-k.

Az iskola szerint viszont a legrosszabbra kell készülni. Az altalad leírtak alapján ebből *érzésre*, sokkal nagyobb baj történhetett volna v. történhet a jövőben. Pár indikátornak tekinthető jellemző:

- a vendor lock-in jelentősége csak most esett le utólag

- ideges voltál, nem tudtál objektíven dönteni, a döntések meghozásában egy fórumtárs best effort supportjára támaszkodtál

- egyedül voltál, hulla fáradtan dolgoztál

- single point of failure vagy (mi van, ha torteniyveled vmi a jövőben v. csak nyaralni mész?)

- ipmi-t kirakod a netre (szubjektív vélemény)

- napi backup van, de azt nem tartod elégségesnek (ezt mondjuk akkor is te tudnad meghatározni leginkább, ha nem te vagy a sysadmin)

- nem volt benned a rutin. h előtte csinálj backupot (persze más is elfelejtheti, de ha jól értem, benned fel sem merült, mint szükséges alap lépés, ami hiányzott)

Valószínűleg lehetne még sorolni, pl. nekem végülis nem világos, mitől szart be a rendszer ennyire, emberi hiba volt-e.

Szerintem te ezt (most és amúgy máskor is) kevésbé tudod felmérni objektíven.

A bias-eid befolyásolnak. Ebben segít, ha retrospektív jelleggel visszanézel, ha van egy társad és az objektivitást erősíti a risk assesment is.

> Ezen kívül az OS-hez korlátozottan értesz (grafikus mankóra van szükséged)

Nincs rá szükségem, ez kényelem. Autóra sincs szükségem ott a  BKV. Luxus autóra pláne nem. Több autóra még annyira sem.

Kösz az analízist. Ne feledd ez egy reflexió, az én önreflexiómra. Na meg, amit megosztottál, mát én is megtettem magamról nagy részben. 

Ugyanis a blogbejegyzésben a szart osztottam meg. Ne abból akarj általánosítani. Azért osztottam meg a szart, mert vannak benne saját hibák bőven, amikből mások tanulhatnak. Ezek nem mind olyan hibák, hogy ez a default gyakorlat nálam.  Ha minden nap ilyen lenne az életem, akkor már megöltem volna magam. :)

> ideges voltál, nem tudtál objektíven dönteni, a döntések meghozásában egy fórumtárs best effort supportjára támaszkodtál
Mint kiderült tudtam. Azt nem tudtam, hogy tudok-e. Pont ezzel a hozzáállással védtem ki számos biast.

Köszi az észrevételeidet. Ilyenekre szükségem van. Tényleg köszi. Pár dolgot általánosságban igazságtalannak érzek, de értem miért írtad amit, mivel mindent nem tudsz rólam, csak azt amit itt megosztok.

Ezt nézed! Elég szarul öregedett: :)

https://hup.hu/comment/2712296#comment-2712296

> - a vendor lock-in jelentősége csak most esett le utólag
Nem igaz, lásd a linkelt szavazás, amit én hoztam létre. Olvasd el mivel nyitottam abban.

> - ideges voltál, nem tudtál objektíven dönteni, a döntések meghozásában egy fórumtárs best effort supportjára támaszkodtál
Ez a fórumtársa, még BBS időkből van, szintén Mensa tag. Nem csak okos, tökös is. kb az egyetlen ember akire rá merném bízni a cégem infráját. Ezt köszönheti a jellemének és a szakmai tudásának.

> - egyedül voltál, hulla fáradtan dolgoztál
Ez igaz. Egyedül vagyok ez adottság. Az volt  a legnagyobb hibám (nem tudásból, hanem személyiségből fakadt), hogy belekezdtem fáradtam. Ilyenkor felületes az ember és túl akar lenni rajta.

> - single point of failure vagy (mi van, ha torteniyveled vmi a jövőben v. csak nyaralni mész?)
Ezzel nem tudok mit kezdeni. A backup ember ez a fórumtárs. Soha nem volt még rá szükség szerencsére.

> - ipmi-t kirakod a netre (szubjektív vélemény)
Szerintem is szubjektív. Ha az a srác vagy, aki a 22-es portot is elrakja trükösen, akkor bele sem kezdek ezt megbeszélni. :)

> - napi backup van, de azt nem tartod elégségesnek (ezt mondjuk akkor is te tudnad meghatározni leginkább, ha nem te vagy a sysadmin)
Amikor 2 óránként csináltam, az megakasztotta a folyamatokat. (sql backup). Ezt valóban újra kell gondolnom. Már van pár ötletem, de tesztelnem kell még őket.

> - nem volt benned a rutin. h előtte csinálj backupot (persze más is elfelejtheti, de ha jól értem, benned fel sem merült, mint szükséges alap lépés, ami hiányzott)

Mindig backuppal kezdek. Most beleszartam. Hinni akartam a csodában. :) Nagyon tetszett a demó a kereskedőnél. Bele sem gondoltam, hogy az OS mit szól hozzá, mert azzal úgy voltam, hogy bármikor helyre rakom egy live linuxszal (egy kubuntu mindig van a kulcsomon) Na ez is pár bias.

Hiba volt az alábbiak nélkül bemenni a hostingba. Ezt full rutintalanságból basztam el:
- laptop 
- mentőeszközök (szerver kapacitás többszöröse)
- csavarhúzókészlet (csak ez volt nálam)
- pendrive Ventoy rajta több OS, köztük system rescue, live disztrók és minden más amire szükség lehet
- kulacs / víz

Mielőtt bemész egyél és igyál. Legyél hidratált. Ne legyél éhes. Ne kelljen wc-re menned. Sőt! A  legjobb, ha azzal kezdesz.

>> - a vendor lock-in jelentősége csak most esett le utólag
> Nem igaz, lásd a linkelt szavazás, amit én hoztam létre. Olvasd el mivel nyitottam abban.

Valóban, ezek szerint korábban is felmerült benned. A mértékét (értékét) mégsem mérted fel helyesen. Eggyel jobb amúgy a helyzet ezzel.

 

>> - ideges voltál, nem tudtál objektíven dönteni, a döntések meghozásában egy fórumtárs best effort supportjára támaszkodtál
> Ez a fórumtársa, még BBS időkből van, szintén Mensa tag. Nem csak okos, tökös is. kb az egyetlen ember akire rá merném bízni a cégem infráját. Ezt köszönheti a jellemének és a szakmai tudásának.

A hangsúly a *best efforton* van. Személy szerint én is sokszor beszoptam, h erre számítottam. Majd amikor szoptam miatta, akkor utána kevésbé:)

A fórumtárs vs. munkatárs azért lényeges, mert az utóbbi ott van veled, proaktívan és tevőlegesen (gyakorlatilag csinalja) segít a munkában. Pl. van access, be is lép, beül az autoban, érdekében áll, h minél előbbre haladjon a dolog stb., tehát ownership van és felelősség. Feltételezem itt nincs szó ilyenről.

 

Egyébként ahogy írod, most szembetűnt +1 gond, amit én kezelnék, ha én lennék a helyedben. Illetve 2 összesen.

 

1. Látszólag eltúlzod a jelentőségét, h vki mensa tag (valójában irreleváns v. kis jelentősége van pl. a rutin es a gyakorlati tapasztalatokkal szemben).

2. Durván bizalmatlan vagy ill. a saját képességeidben, túlzottan bízol (látszólag), ami hosszú távon kontraproduktív és részben ennek lett az eredménye.

Igen, megintcsak a meglévő limitált információk alapján írtam, simán lehet téves:)

 

A bias-okról:

https://dev.to/x-team/12-hurtful-cognitive-biases-and-how-to-overcome-t…

Ha te ismerted, akkor másnak. Biztos vannak, akiknek újdonság. Nekem anno sokat segített, h vki más megfogalmazta őket.

ps: Természetesen nekem is megvannak a saját bias-aim és pl. eltúlozhatok tényezőket és rosszul ítélem meg.

> Valóban, ezek szerint korábban is felmerült benned. A mértékét (értékét) mégsem mérted fel helyesen. Eggyel jobb amúgy a helyzet ezzel.
Mit tehettem volna? Az R310-ben a Perc-H700  mint kiderült nem is tudja a NON-RAID módot. Vagyis amikor felmerült bennem, kapásból kellett volna vennem egy másik szervert.

Az itteni barátom, nem tekinteném best effort-nak. Csak egy plusz lehetőség. Egyfajta mentor, mert inkább én tanulok tőle IT-t, ő meg mást tőlem. Ő pár ezres számú gépet üzemeltet, míg én kb 200 eszközt és ebből 3 szerver van csak. Rengeteg IT-s van ebben az országban, akik egyedül dolgoznak és a többségnek van olyan barátjuk, aki másban erős, akihez fordulhatnak pár adott témában. Nem mindenkinek adatik meg a csapat. Megjegyzem a csapat sok esetben csoportos lúzerkedés, ahol egy ért hozzá és vele utazik pár potyautas. Ebből nekem bőven kijutott már az életben, köszönöm ez a következőre életemre is elég lesz. Nem akarok másokat  harcközben lőni tanítani. Persze mondhatnád azt, hogy keressek egy okosabbat, akitől tanulhatok. Majd adok fel hirdetést. :P De mit írjak bele? Munkaidő  25 évente 1 nap? :)

1. Gyorsan ítélsz. Nem túlzom el, megemlítem, te érzékelted fontosabbnak, ami neked nem tetszett és emiatt reagálsz. A magas IQ elősegíti, hogy kevésbé állatias üzemmódban érzelmekkel túlfűtve hozzál meg döntéseket. Ennyi. Nem leszel tőle jobb szakember vagy jobb ember. Abban segít, hogy hamarabb megérts dolgokat. A munkát a tanulásban nem úszod meg. Miközben ez az esemény történt velem 4-5 terv ment a fejemben, és tudtam dönteni / választani köztük. A blogbejegyzés kifejezetten a balfaszságot hívatott bemutatni. Ennek oka, hogy más hibájából tanulni percek, míg más amit jól csinál néha egy élet is kevés el lesni. Amikor új dolgot tanulok, azzal kezdem már az első időszakban, hogy rákeresek a tipikus hibákra az adott területen, hogy spóroljak magamnak időt és pénzt. Ezt másnak is javaslom. Emiatt készült  a blogbejegyzés.

2. Tapasztaltnak hívják. Abszolút mindenkinek van nálam esélye, amit nem a tudás hiányával veszít el, hanem a jellemével, a töke hiányával. Kontra-produktívnak nehéz engem nevezni, egyfajta valóság tagadás lenne, mivel a teljesítmény objektív mérő száma a pénz. Abban pedig durván jól állok. 

A bias-ok nekem nem újdonság.  Minimum egy polcnyi pszichológiai könyvem van, amit olvastam is. A sok érdeklődési területem közül ez az egyik. Nincs olyan nap, de inkább pillanat, amikor nem azonosítanám az érzelmeimet. Roppantul szórakoztat ez engem. Mint a blogbejegyzésből is kiderülhetett, ez az önvizsgálat a szerverteremben is velem volt. Sőt, a blogbejegyzésben is fellelhető. Te e bejegyzés miatt azt mondod kb keressek magamnak üzemeltetőt, eközben én, ha ilyet látnék azonnal felvenném az illetőt bármire, mert emberileg pipa. Van tök a láb között és van önvizsgálat. Hogy miért venném fel azonnal? A tudáshiány pótolható, a jellem, a tök nem.

Itt egy jobb oldal a biasokról:

https://viselkedestudomany.hu/

Adok én is visszajelzést neked: a biasok felületes ismeretével Dunning-Kruger hatás alá kerülhetsz. Óvatosan vele. 

> Mit tehettem volna? Az R310-ben a Perc-H700  mint kiderült nem is tudja a NON-RAID módot. Vagyis amikor felmerült bennem, kapásból kellett volna vennem egy másik szervert.

Rakhatod 1 diszkes raid0-ra (zfs eseten ilyenkor ez eleve az ajanlas).

Egy kicsit kizoomolva, hogy alakitanam ki (at) en a helyedben ezt a rendszert, azt is elmondhatom, ha erdekel, de inkabb csak privatban. Ha erdekel.

Semmi kedvem a fotelharcosok kopkodesehez:)

 

> Az itteni barátom, nem tekinteném best effort-nak.

Abban neveztem best effortnak, h ha olyanja van, segit, ha nem, akkor nem. Ha nincs kedve nem segit es az teljesen OK, ha nincs ideje, akkor sem stb.

Nem vallal felelosseget es ownershipet a problema megoldasaert.

Ez fuggetlen attol, h a baratod, mensa tag, 2000 szervert uzemeltet v. nem.

 

> Rengeteg IT-s van ebben az országban, akik egyedül dolgoznak

Csinaltam sokaig, ismerem az elonyeit es a hatranyait.

 

> adatik meg a csapat

Eros szo az 'adatik', magatol tuti nem:) Pl. valoban, tipikusan koltsege van altalaban, bar talan, nem feltetlenul direkt.

Szerintem egyebkent most mar elbeszelunk egymas mellett.

 

> a csapat sok esetben csoportos lúzerkedés

Nade miert ne epitenel v. keresnel olyan csapatot, amelyik jol mukodik?

Ezt a felvetesed egyaltalan nem ertem.

 

> Adok én is visszajelzést neked: a biasok felületes ismeretével Dunning-Kruger hatás alá kerülhetsz. Óvatosan vele. 

Tisztaban vagyok vele, mennyi sokat nem tudok. Azzal is, h minel elobbre haladok, annal inkabb latom, h mennyi tovabbi sokmindent nem (es nem is fogok).

Kosz a linket, majd megnezem.

( Dwokfur v | 2023. 04. 25., k – 14:49 )

Az kiderült, hogy miért nem engedett oregon-ként semmit csinálni, amikor lehetett chroot-olni?

Milyen file system volt?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nem derült ki, a fókusz is lement róla. Ext4 volt.

Tipp: A Linuxos raidvezérlő kernel modul szerintem nem vett tudomást a hw cseréről. Ezt abból gondolom, hogy a hibaüzenet ezen modulra szólt, valamint egy friss install vagy a live alól ez a gond nem jelentkezett  Az új H755 kb egy napig nyomott egy rebuildet, de ettől még a Linux alatt semmi sem változott. Installálni a rendszer nem engedett semmit. Opció lehetett volna a live alól felülcsapni a rendszert, de ehhez nem volt tököm.

Hibaüzenet és a találatok (Ez nem a disk cserénél jelentkezett, hanem később, amikor már otthon voltam. Gondolom kellett neki valamennyi sync. Innentől nem tudtam csinálni semmit.):

https://www.google.com/search?q=megaraid_sas+0000%3Ac3%3A00.0%3A+fw+in+…

A driver rosszul fogja az fw-t. :)

Attól függ kit kérdezel, a Dell-t vagy Linux Torvaldsot :)

A Dell azt mondta, a hdd-k mennek, mert elindul a boot folyamat. Innentől OS. Mivel a szűz install megy a gépen hiba nélkül, így az érvelésük elfogadható. Ha fw bug lenne (mondják ők), akkor az új rendszernél is elszállna az OS. 

( bognarattila | 2023. 04. 26., sze – 19:15 )

Meglep, hogy ennyire fillérbaszó vagy a cégedben :-)

Szerintem mormolj egy imát, hogy eddig nem futottál bele ilyenbe vagy hasonlóba, a leírtak alapján kódolva volt.

Legegyszerűbb megoldás:

- két szerver, két különböző helyen
- VMware ESXi, Essentials licenc nem drága (de akár az ingyenessel is működik, hangyányit bonyolultabb)
- VM szintű replikáció ízlés szerinti gyakorisággal, néhány óránként sima ügy, leírtak alapján felesleges gyakrabban
- egyik telephelyen mentés pl. NAS-ra

Mindkettő ESXi-re teszel egy virtuális tűzfalat, alatta megfelelően VLAN-ozni, VPN-nel lépsz be.

Ha failover kell, átirányítod a forgalmat a másodlagosra (akár DNS, akár VPN), részleteket nyilván ki kell találni helyzettől függően, de nem atomtudomány.

ESXi helyett nyilván lehet mást használni, de az tapasztalat szerint évekig teszi a dolgát, mentési technológia is stabil, cbt nagyon hasznos.

Tervezetlen átállás RPO=néhány óra, tervezett átállás RPO=0.

RTO így rajtad múlik, de az átálláshoz fekete öves informatikus sem kell, csak egy jó dokumentum képernyőképekkel és előkészített notebook.

Licenc így nem nulla forint, de nem is csillagászati, cserébe nincs kínlódás, működik, kényelmes, kiszámítható, nyereséged ~fél százalékából megvan.

"Meglep, hogy ennyire fillérbaszó vagy a cégedben :-)"

Engem is meglepett. El is gondolkodtam miért csináltam ezt eddig. Arra jutottam, hogy azért, hogy ne az legyen, hogy a hobbimat beviszem a  cégbe. Mindig bűntudatom volt, ha IT-ra költöttem.

> Ha failover kell, átirányítod a forgalmat a másodlagosra (akár DNS, akár VPN), részleteket nyilván ki kell találni helyzettől függően, de nem atomtudomány.
Az a baj, hogy az. DNS-ek nem állnak át egyből. Az esetek többségében a problémák max perceket vettek igénybe, ezt egy DNS átállás nem tudja.

Eddig a mentést egy ProLiant MicroServer Gen8 végezte. Ma vettem helyette egy T640-t.  Ebben van hely 8 disknek, szóval gazdagabb mentést tudok csinálni, amellett egy full meleg tartalékot. Eddigi megoldásom az előző napi mentésből visszaállás kb 15 perc lett volna. Az eset kapcsán jöttem rá, hogy ez kevés.  Korábban 2 óránként volt mentés (sql dump), de ez az sql miatt problémákat okozott az üzemelésben így leálltam vele.

Keress objektív számot arra vonatkozóan, hogy hozzád hasonló cégek mennyit szoktak IT-re költeni, vesd össze a saját költéseddel és akkor lehet, hogy megnyugszik a lelkiismereted :-) Pl. a bevétel 2-3%-a egyáltalán nem túlzás, sejtésem szerint 0,5-1% körül mozoghatsz.

Ha nem szeretnél drágább megoldást, akkor kompromisszumot kell kötnöd, ez praktikusan a tervezetlen leállás RPO. A VM replikáció inkrementális az sqldump-pal ellentétben. Igaz, a pillanatkép készítésekor "döccen" a VM, emiatt nem célszerű túl gyakran replikálni, gyors szerverrel ez a döccenés csökkenthető, illetve "agent" megoldással is.

DNS: alacsony TTL-lel szerintem nem lehet gond (biztosan nem nagyobb, mint a performanszod következménye :-) ), de ha a két szervert egymás mellé rakod, akkor van egy olcsó HA-d. A két tűzfal is legyen HA-ban és akkor az automatikusan át tud állni, pl. OpnSense.

Telephelyen kívül mentésre pedig lehet egy harmadik szerver, szintén replikálva rá a rendszereket, ennek használati esélye nullához közelít.

A VM alapú megoldások azért is jók, mert csak egy rendszert kell karbantartanod, szinte minden rendszer szinte egyformán kezelhető, sokkal kevesebbet kell gondolkodni, leírást keresni stb. Tapasztalat szerint nehéz jó leírást készíteni, helyzetben pedig nagy kincs az egyszerűség.

Ha helyi tervezetlen leállásra RPO=0-t szeretnél és automata failovert, akkor drágább lesz, bármilyen technológiát is választasz: választástól függően a szoftver, hardver vagy tudás viszi el a költséget.

Másik opció (másféle kockázattal, akár kiegészítésként) NBD helyett magasabb rendelkezésre állású hardver garancia szolgáltatást igénybe venni.

És akkor ez csak a rendelkezésre állás kérdése, az IT biztonság is egyre kritikusabb a zsarolóvírusok korszakában. Alap a megfelelő VLAN-ozás és tűzfal korlátozások, a mentések védelme.

"Keress objektív számot arra vonatkozóan, hogy hozzád hasonló cégek mennyit szoktak IT-re költeni, vesd össze a saját költéseddel és akkor lehet, hogy megnyugszik a lelkiismereted :-) Pl. a bevétel 2-3%-a egyáltalán nem túlzás, sejtésem szerint 0,5-1% körül mozoghatsz."

0.2% alatt

"Ha nem szeretnél drágább megoldást, akkor kompromisszumot kell kötnöd, ez praktikusan a tervezetlen leállás RPO. A VM replikáció inkrementális az sqldump-pal ellentétben. Igaz, a pillanatkép készítésekor "döccen" a VM, emiatt nem célszerű túl gyakran replikálni, gyors szerverrel ez a döccenés csökkenthető, illetve "agent" megoldással is."

Ez a döccenés miatt álltam le a napközbeni többszöri sqldumpo-ról. Problémát okozott. (Kódolással javítható lenne, de workaround, inkább a crontab -e  volt :))

> Telephelyen kívül mentésre pedig lehet egy harmadik szerver, szintén replikálva rá a rendszereket, ennek használati esélye nullához közelít.

Minden privát gépem (5 db) amikor online van (1 mindig), akkor nyom egy sync-et.

Én is egyszerűség párti vagyok.  Arra gondoltam, lehet ki kellene bloggolnom az infrát, maszkolva az ip-kkel. Ekkor lenne egy online manuálom és a köpködések miatt tanulhatnék belőle.

RPO=0 szerintem aránytalanul drága lenne nekem.

Biztonság: egyetlen egy user vagyok a rendszerben. Mindenki más csak webről éri el. 

"Biztonság: egyetlen egy user vagyok a rendszerben. Mindenki más csak webről éri el. " - Ilyet már láttunk, hallottunk... Aztán valahogy az a "csak webről" elég volt ahhoz, hogy sok-sok adatot kitalicskázzanak a rendszerből. A biztonság relatív: ha csak te vagy user, akkor csak a te - esetleg hibás, vagy nem kellően biztonságos irányba ható - döntéseid azok, amik a rendszer működését, megbízhatóságát, biztonságos üzemvitelét befolyásolják. A "négy szem" jó dolog tud lenni, pláne biztonságot érintő kérdésekben. Ahogy egy tanult kolléga megfogalmazta: a biztonság nem állapot, hanem folyamat. A korlátozott hozzáférés _legfeljebb_ a szükséges feltételek közé sorolható, de messze van az elégségestől.

A teljes DB-dump nem arra való, hogy RPO-t minimalizáld. Ha nulla közeli RPO a cél, akkor aktív+meleg tartalék DB-szerver felé célszerű nézelődni: gyakorlatilag minden valamire való RDBMS-hez található log shipping-en alapuló "langyos" tartalékolásra megoldás. (Ha automatikus failover-t is szeretnél, akkor 3 node alatt nem úszod meg, bár a 3. az adatok nélküli "witness" node, gyakorlatilag nulla erőforrásifgénnyel)

Pár óra leállás nem téma nálam. Inkább csak adatvesztés nélkül akarom megoldani. De csak azért, mert macera egy kis adatvesztés is. Szerintem ezt már az SW raid-del és újragondolt mentési stratégiával megoldva. Minden más már a leállás csökkentéséről szól.

Először csak 0,5%-ot akartam írni, nem akartam sértő lenni + nem gondoltam volna, hogy annál is FB-bb :-)

Van ügyfél, aki a mentéseket VM alapúról átállította Agent alapúra a döccenések miatt, azóta boldog az SQL az ipar 4.0 alatt.

"RPO=0 aránytalanul drága": ha ilyen vígan kibírtad a szervercsere problémát, minden bizonnyal igen :-)

"Egyetlen user": csak te dolgozol? Fájlszervered sincs? Webshopon keresztüli felnyomás?

- :)

- Nem tudom mit jelent az Agent alapúság. Sima sqldump?

- Megbocsátóak az ügyfeleim. Mondjuk volt aki ma azzal poénkodott, hogy ha kell átküldi az IT-sát. Ezt azért merte, mert tudja, hogy nem bánt meg vele. Az ügyfeleim tudják mit raktam össze, mert ők is abban a rendszerben tevékenykednek. Eddig csak elismeréssel találkoztam.

- Minden használatban lévő kódot én írtam, csak az én gépeimen létezik. Nem vagyok target. Van pár WP-m is, de azok karanténban. :)

Agent alapúságot kétféle módon értem: OS-ben fut egy szolgáltatás, ami "image" szintű mentést tud készíteni. Ebből talán nem lehet replikálni, de naponta többszöri mentés mehet. Illetve olcsóbb megoldásból a Veeam-nek már van CDP-je, ez hipervizor szinten dolgozik és nincs semmilyen pillanatkép, néhány mp-es az RPO. Ezt még nem használjuk élesben ügyfélnél (vannak megkötések, amik nem találkoznak az elvárásokkal), de van másik hasonló technológia, ellenben az sokkal drágább, de teljesen jó, ha be akarod hozni az elmaradt IT kiadásokat, jelezd :-)

Ettől függetlenül a VM szintű replikációnál sem feltétlenül akkora a döccenés, hogy gondot okozna, ez alkalmazástól és terheléstől függ. Jellemzően akkor van gond, ha hosszabb lekérdezéskor történik ez, illetve az alkalmazás nem képes magától új kapcsolatot létrehozni szakadás esetén. Pl van Sharepoint + SQL Server, ahol még sose volt rá panasz.

Ezek inkrementális technológiák, ha nem youtube vagy, akkor jó eséllyel nem vészesek a változások.

Érdekelne, miként éred el az RPO=0-t, próbáltam keresni a leírást, de nem találtam meg a hozzászólások között. A szoftver RAID 1-2 speciális esetben jó, de amúgy inkább hardvereset kellene használni, teljesítményre is jobb. Az régen rossz, ha az üzletmenet folytonosság a RAID technológián múlik. Vedd azt alapul, hogy túláramot kap a rendszer és minden elromlik benne, ebből kell mielőbb felállni, minél kisebb veszteséggel. Mondjuk úgy, hogy éppen Olaszország déli részén vagy.

Nem szeretném kicsinyíteni a képességeidet és érdemeidet, de a túlzott magabiztos hozzáállás veszélyes lehet, a szerver csere művelettel magad is beláttad, ezt a tanulságot érdemes lehet más tevékenységre/aspektusra is kivetíteni. Ha egy feltörés/vírus miatt mindent lezúznak, akkor már nem biztos, hogy annyira poén lesz, főleg ha a 0,2% felugrik egyszeri 10-20%-os kiadásra egy titkosító kulcsért. Egyrészt te is véthetsz hibákat, másrészt PHP stb keretrendszerek is lehetnek hibásak, végül az Apache is lehet gond. És még sok minden más.

De hát mindenki ott cseszi el, ahol akarja :-)

A privát wp oldalakat akár ki is lehet váltani valamilyen statikus site generátorral és ezzel is csökkenthető a támadási felület. publii, Hugo és hasonló szoftverekre gondolok.

Azt miből gondolod, hogy a céges webshoppal nem vagy target? Van előtte bármilyen WAF? DDoS jellegű támadásokra van már terved? Illetve a két topic hozzászólásait átfutva nem láttam semmi utalást OT Security jellegű tevékenységre.

Wp oldalak:  külön vps-ben vannak, nem kár értük, automatikusan frissülnek, nincsenek legacy kóddal felpluginezve, kockázat a user és a zeroday

Látom, minden támadás valamilyen ismert sw ellen irányul. Ilenkor a 404 kisebbterhelés, mint generálni egy captchat

Ezeket használom: fail2ban, iptables, rkhunter

"Látom, minden támadás valamilyen ismert sw ellen irányul." - Nem. Egy támadás adott, a neten elérhető szolgáltatással jelen lévő entitás ellen irányul. A "csak a te gépeiden létezik az adott sw" az más megfogalmazásban a "security by obscurity" elv, ami khm. finoman fogalmazva is erősen túlhaladott dolog.
Ha target leszel, akkor fognak keresni, és vélhetően találni rajtad, rajtatok fogást -  hogy mennyi erőforrást tol bele valaki egy ilyen támadásba, az attól függ, mennyit ér meg neki az, hogy a megtámadott entitásnak kárt/kiesést okozzanak, vagy "csak" adatot vigyenek el tőle.
 

"security by obscurity"

Nem erre gondoltam. Arra, hogy a default scriptekkel, ismert webes rendszerek ellen való támadás kudarcra van ítélve nálam. Innentől kezdve csak target lehetek, ha sikeres akar lenni valaki, ahhoz meg nem vagyok elég értékes.

Ha target leszek, majd akkor visszatérünk erre. Simán lekapcsolom a szerverem egy húzósabb esetben. Anno, még a 90-es években volt, hogy erre kényszerültem, mert akkor még a hálózaton keresztül le lehetett könnyen fektetni egy rendszert sima pingeléssel is.

 

ps.: Amúgy ne csináljatok már abból versenyt, amiből az derülne ki, hogy mindenhez is hülye vagyok. :) Nem hinném, hogy akkor mázlista volnék, hogy túléltem 25 évet és a mostani "akciómat" is. Ez nem mázli. Nem szerencse és nem is véletlen. 

"a default scriptekkel, ismert webes rendszerek ellen való támadás kudarcra van ítélve nálam" - ennél picit bonyolultabb a dolog.

"Ha target leszek, majd akkor visszatérünk erre. Simán lekapcsolom a szerverem egy húzósabb esetben." - csak egy keresztkérdés: honnan fogod észrevenni?
 

Nincs itt semmilyen verseny, csak ha ezt-azt még jobban csináltál volna, ez a kaland sem jött volna létre.

Ez az egész IT kicsit olyan, mint a biztosítás: minek kössek jövőre, ha eddig sem volt semmi? Ügyes vagyok, hogy eddig nem égettem le a házamat, ezután sem fogom.

Nemcsak WP&Co próbálkozások vannak, egyszer nálad is betalálhat valami és a kérdés akkor az lesz, hogy meddig jutnak el, mit tudnak törölni/titkosítani. Mivel nyilvános, hogy mennyit tudnak rólad legombolni, ezért rögtön célpont lehetsz. De hát majd akkor is le tudod annyival, hogy túlságosan magabiztos voltam :-) Azt pedig csakis te tudod megítélni, hogy ez mennyiért ér neked. :-)

Az ilyen dobozos megoldásoktól vannak félelmeim, mint a proxmox. Ez sem ok nélkül. Anno a Zenthyalba sokakkal együtt beleszerettem. Majd egy distr-upgrade és lehalt minden. Velem együtt, sokak ekkor kiszerettek belőle. Hol van ma már a Zenthyal? Semmit sem hallunk róla, én már embert sem ismerek aki ilyet telepít. Nem lennék meglepve, ha a proxmox is idővel erre a sorsra jutna.

Sokan, akik egy X-re köpnek amikor szerverre kerül, simán beemelnek egy ilyen réteget, mint a proxmox varázslat. Szerintem az X kisebb kockázat, mint egy ilyen absztrakciós réteg.

valszeg valami qemu magic. nemtudom, nem neztem eddig utana. de tenyleg mukodik, kiprobaltam. ha tippelnem kene, akkor bitmappal nyilvan tartja hogy melyik blokk van mar disken, es melyiket kell egy masik helyrol olvasni. a backupolas is mar bitmap alapu (memoriabol): azokat a blokkokat menti amik valtoztak az utolso mentes ota. igy nem kell a sok T-s diskeket felolvasni mindig.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( trey | 2023. 04. 27., cs – 13:20 )

Szerkesztve: 2023. 04. 27., cs – 13:21

Valamint, soha ne bízz a LED-ekben! 🙂 Szépen világított az USB-SSD LED-je, de otthon derült ki, hogy az annyit tesz: áram alatt van, lsusb viszont nem látja. Mountolni nem tudom. 🙁

:D :D :D

Nem mondok inkább semmit. Hiszen, ez nem mérnöki munka. Smarthand-ed nem volt kéznél?!

trey @ gépház

Tehát, összefoglalva:

  • nem értetted meg, hogy ott mikről beszéltem, sebaj, még pár ilyen szopóroller kör és majd megfogod
  • továbbra sem érted, hogy miért hiányoznak a szaktanfolyamok a fejedből
  • nem tanultál semmit, pedig nincs két hete, hogy ezt a szopást előrevetítettem neked

:)

trey @ gépház

Ez a ledfigyelés a te faszságod. Tudatlanságodból fakadóan valamit félreértettél és azóta azon lovagolsz.

Visszatérve a témára, a RAID konfig felolvasása a diszkekről és importálása az egy létező téma, ha két UGYANOLYAN (vagy egymással 100%-ban kompatibilis -> compatibility matrix) RAID vezérlő közt végzed, illetve nem csak, hogy ugyanolyan, hanem még ugyanazon a firmware level-en is vannak. 

Ezt minden valamirevaló hw mérnök tudja, mert megtanulta.

Azt is mondtam, hogy te egy darab PC-be hányt low budget RAID vezérlő + néhány diszk setup-on is megcsüngenél, ha valami gebasz bebaszna (meg is történt), nem tudom mit szólnál, ha egyszer találkoznál egy komolyabb storage rendszerrel, ahol nem csak erre, hanem még 1000 másik dologra is figyelni kell, hogy ne legyen a végén kormos pofa ... 🤷‍♂️

De, persze, én csak hülyeségeket beszélek. Majd alkalomadtán ezeknek kérdezz utána valami rendes mérnöknél.

(Ha ezeket megtanultad volna, nem szoptál volna egy idegben két napon keresztül. Vagy esetleg megkérdezted volna tőlem, elmondtam volna. Párszor ezeket mondjuk elmondtam itt a HUP-on az elmúlt 20 évben, de sokszor csak röhögés jött. Nekem aztán édes mindegy, hidd el :)

trey @ gépház

Szeretem mindegyiket. Problémában nincs szignifikáns különbség a kettő között. Szoktak működni, max. diszkhibák vannak. Komolyabb hibák nagyon ritkán.

Egyszer volt egy olyan egy Fujitsu DX80-nal, hogy szabályos, tervezett leállítás után a mindkét kontroller meghibásodott. Nyilván, nem a hardver ment tönkre egyszerre mindkettőben, valami firmware hiba volt, amit nem lehetett orvosolni, csak cserével.

Az cumi volt, mert nyilván azért van benne kettő, hogy ne legyen single controller hibából probléma. Az okozott néhány órás leállást, mire a szakszerviz odaért két működő kontrollerrel. De ilyen hibával 20 év alatt egyszer találkoztam.

A legnagyobb hibák a diszkhibák szoktak lenni.

trey @ gépház

Nekem semmilyen szelvényem nincs, mert ahogy elmondtam azt is milliószor, azért nem legózok, meg barkácsszakkörözök, mert a gyári support megoldja. Ebben az esetben egy telefon volt a SERCO-nak, szerintem 2 óra alatt leért a szerviz az alkatrésszel Bp-ről. Betették, boot, munkalap aláír, viszlát, helló, minden ment tovább.

trey @ gépház

Elnézést, hogy belekotyogok: biztos többet szívott már, mint te, valószínűleg ő is bénázott már, de gyaníthatóan más a merítés/arány.

Aztán megtaláltam, hol írod a sw raid-et: "Az nem fér bele, hogy az adataim egy RAID vezérlőtől függjenek, így az SW Raid mellett döntöttem. Hiszen reális kockázat az, hogy ha egy ilyen kártya meghal, csak újabbat kapok, akkor ugyanígy járok." - ez a szemlélet egy zsáknyi szelvény a szopólottón. Ott kezdődik, hogy garancia támogatás nélkül nem üzemeltetünk szervert (legfeljebb ha kellő személyzet és mennyiség van, hogy gazdaságos legyen megfelelő tartalék alkatrészt tartani). Tudod, biztosítás, amibe bele sem akarsz menni... :-)

Inkább az ilyen firmware jellegű és egyéb "kiszámíthatatlan" problémákra gondolok, hogy a hozzám képest jelentősen nagyobb merítésből nálad mi csapódik le. Pl. HP(E) esetén rendszeresen problémák vannak a firmware-ekkel (valami fagy, szakad, ...), Dell és Fujitsu esetén közel sem találkoztam ennyi ilyennel.

Hm.  Köszi.

Gondolkodtam rajta. Ha a hw képtelen rá, akkor a helyes eljárás az, ha meg sem próbálja. Nem pedig az, hogy csakazértis. Mivel a Perc kiolvasta a configot, vélelmezem az tartalmazta, hogy ki csinálta a tömböt. Arról meg neki kellene/illene tudni, hogy ilyenkor mi a teendő.

Egyfelől igen, ilyen esetben rákérdezhetne, hogy inkompatibilis konfigurációt talált, mi legyen (de lehet, hogy nincs kellő metaadat információ; az is kérdés, hogy biztos nem kérdezett-e rá, de te úgy gondoltad, tudod, mit akarsz), másfelől ez nem egy háztartási porszívó, hanem informatikai céleszköz: aki ezt bizergálja, az remélhetőleg tisztában van kompatibilitási függőség lehetőségekkel és ilyen drasztikus művelet előtt tájékozódik, ha mégis átteszi, akkor tudja, miért teszi.

Kicsit hasonló példa: volt egy kollégám, aki nálad is nagyobb magabiztossággal tudott dolgoknak nekiesni, LVM kötetet kellett másik VG-re migrálnia. Lényeg, hogy a /dev/vg0/foo-t normál fáljként kezelte: azt másolta, rsync-elte, törölte és még néhány hasonló, már nem emlékszem pontosan. Mondanom sem kell, az LVM alrendszer ezt nem igazán honorálta, adatok vesztek el (szerencsére nem éles rendszeren). Ennek kapcsán gondolkodtam azon, hogy az rm, mv, cp és hasonló parancsok ilyenkor miért nem figyelmeztetnek. Valószínűleg azért nem, mert aki LVM-mel dolgozik, nem jut eszébe ilyet csinálni, ha mégis olyat csinál, akkor tudja, mit akar.

Korábbi kommentem tudnám ide is idézni:

Nem, hanem okkal csinálják ezt. Ugyanis az emberek szeretnek mindent "megjavítani". Minél kisebb a hozzáértés, annál nagyobb szokott lenni a javítási kedv. Ugyanis, aki ért hozzá, az pontosan tudja, hogy hogyan lehet kajak elbaszni, ha nem odafigyelve csinálja, így van benne egy egészséges megfontoltság. A dillettánsban nincs ilyen gát, hisz nem is érti, hogy mekkora kárt tud okozni.

trey @ gépház

De, válasz. Az a szakember, aki megfelelő, gyártó által igazolt szakképesítéssel rendelkezik, van x év tapasztalata és ha az ügyfél/feladat megköveteli, megfelelő felelősséget tud vállalni a munkájáért, mert olyan tőkeerős cég áll mögötte, vagy mert olyan felelősségbiztosítással rendelkezik.

trey @ gépház

Amit írsz az kb azt jelenti, lehetőleg mindenki 20 év tapasztalattal kezdjen el dolgozni. Ha nincs neki, akkor meg bízza szakemberre. Most már csak azt kellene megálmodnunk, hogy hol készül a szakember. Valami "safe space"-ben?

Az, hogy így gondolkodtok nem valami életközépi válság eredménye, ahol szakmai egzisztenciális válság is jelen van?

Nem azt jelenti. Azt jelenti, hogy mielőtt valamihez hozzápiszkálsz, tájékozódj. Írásaid alapján Te is szoktál, itt azt szívtad meg, hogy hittél a kereskedőnek. Neki illett volna tudnia, hogy lehetnek kompatibilitási korlátok és ezt jelezni feléd. Neked illett volna óvatosnak lenni, főleg, mivel produktív szolgáltatásról és adatokról volt szó.

Kereskedők gyakran hajlamosak tévedni, átsiklani részletek fölött, hiszen neki elsősorban az aktuális ügylet lezárása a prioritás, arra koncentrál. Ettől függetlenül mérnököknek sem szabad mindent elhinni, főleg ha a saját bőrödet viszed a vásárra.

Nem világos, a hozzászólásban mi utal válságra. Tapasztaltunk már ezt-azt, óvatosabbak vagyunk, mint 20 évesen.

A szakember pedig képződik az évek során, a tapasztalatok által, ez szerintem mindenhol így van.

"Nem világos, a hozzászólásban mi utal válságra. Tapasztaltunk már ezt-azt, óvatosabbak vagyunk, mint 20 évesen."

Az a tény, ha valaki kevesebb hozzáértéssel és még hibák halmazával áll(t) hozzá, akkor eltanácsoljátok a  tevékenységtől. Nem értem miért. Biztos van mögötte motiváció.
Munkában mi a hozzáállás egy frissen végzetthez?

"A szakember pedig képződik az évek során, a tapasztalatok által, ez szerintem mindenhol így van."

Akkor most mi tegyek? Ne csináljam vagy csináljam?

Hol volt eltanácsolás?

Akkor most mi tegyek? Ne csináljam vagy csináljam?

Én nálad érzékelek válságot :-)

Lemaradt: frissen végzett egyrészt kevésbé kritikus feladatot kap, másrészt ha úgy hozza szükség, részletesebb instrukciót kap és/vagy szorosabb felügyeletet. De egyén függő is.

hogy hittél a kereskedőnek. Neki illett volna tudnia,

Hát, ebben sem vagyok biztos. Olyan magabiztosan állítanak magyarországi disztribútorok (nem nevezem meg őket) (pre)sales emberei óriási baromságokat, hogy az embernek égnek áll a haja. Amikor átküldjük, hogy mit szeretnénk a product bulletin-ből, majd megokoskodják, hogy "de működik az mással is" (mert éppen az van raktáron), aztán, amikor kiderül, hogy nem, akkor meg meg a magyarázkodás.

trey @ gépház

Nagyon nehéz rövid idő alatt leszűrni ki mihez ért. Azt szokott hamarabb kiderülni, mihez nem. Ez itt is megvolt, hogy a Linuxhoz a sales csak korlátos ismeretekkel rendelkezik. A szervizeseknél már érezhető volt a tapasztalat, de semmiképpen nem semmisültek meg, mert válaszaik relevánsak voltak. Kérdéseket értették. Ők demóztak, nem sales.

Azzal az ismerettel, hogy gond lehet nem rendelkeztek. Mivel vettem még egy gépet tőlük, elmeséltem nekik a történetem. Meglepett arcok voltak.

Ebben nincs tapasztalatom. Azzal a bizalommal álltam hozzá, hogy az emberek értenek ahhoz amit csinálnak. A logikát követve: Emiatt egy "rendszergazdát" is hasonlóan beszopnék, mint ezt az eseményt. Ebből adódik, hogy csak egy réteget hoznék be vele, nem megoldást, mert ahhoz pont ugyanúgy nincs meg tudásom, hogy kiválasszam a hozzáértőt, mint ahogy ahhoz sincs, hogy kiválasszam a megfelelő kereskedőt.

Igen, a kiválasztás egy örökös probléma, de nemcsak IT területen, ahol van sok "szakemberes" cég kiváló gyártós plecsnikkel, akik szintén bődületes baromságokat tudnak csinálni. Csak egy kiváló példa: banki tároló architektúra, ahol az iSCSI és kapcsolódó forgalmak nem redundánsak, állítólag gyártói közeli közreműködés is volt a megvalósításban. Ettől függetlenül azért jó esély van rá, hogy egy szakcég is megfelelően (vagy legalább jobban) kezel egy tiedhez hasonló helyzetet.

Ugyanakkor az a megfogalmazás, hogy kereskedő csak egy műkedvelő, általánosan igaz minden területre (ezt hasznosítani fogom, ha nem gond). Kivételek nyilván mindenhol vannak (kereskedő ért hozzá és tudja+kommunikálja a korlátait), általában azért azok a sikeresebb kereskedők, akik rendelkeznek valamiféle határozottsággal, az igazságtartalomtól függetlenül. Ezt az üzleti életben is megtanulhattad volna, IT-től függetlenül.

Veled - ismétlem magamat - az a probléma, hogy túlságosan határozott vagy. Írhatnám, hogy a témát feldobhattad volna itt a kiváló HUP-on, biztos sok hasznos tippet kaptál volna, de fel sem merült benned, hogy van kritikus rész. Ugyanígy fel sem merül benned, hogy a weboldal biztonsági kockázatot jelent, amire célszerű felkészülni, pedig jelezve lett. Tőlem a biztonsági szakterület kicsit messzebb áll, Zellerhez tuti közelebb, amennyire ismerem a múltját és jelenét.

A kertészünk pedig azt mondta, hogy az a legrosszabb, mikor a hülyeség szorgalommal párosul. Jelen esetben az enyhítő körülmény, hogy saját bőrödet viszed a vásárra.

b) vagy b+a) attól függően, mennyi időd van. Azért nem a), mert hobbiként tekintesz a témára és úgysem bírnád ki, hogy nem folysz bele, továbbá a saját alkalmazásodat Te ismered.

A tanulást kb ott kellene kezdeni, hogy raid vezérlő választási szempontot felülvizsgálni pl úgy, hogy a szerverre mindig legyen garancia és akkor az alkatrész nem fog gondot okozni. A garancia szintjét kell kiválasztani, azzal tisztában kell lenned, hogy pl az nbd garancia nem jelenti azt, hogy másnap elkészül a javítás, a rendszer kritikusságától függően szükséges lehet hideg/meleg tartalék. Egy kereskedő ezt lehet, hogy nem fogja kihangsúlyozni, esetleg nem is tud róla.

Én is így látom. Már korábban arra jutotta, hogy a szerver OS és a mindennapos OS a lehető legközelebb kell lennie egymáshoz. Ennek oka, hogy aki PHP-ben fejleszt és nem konténerben futtatja az alkalmazását, annak sajnos szívás a Debian, a csomagok elavultsága miatt. Emiatt is használok, mind szerveren, mind desktopon Ubuntu LTS-t. A teljesen azonos körülmények, nagyobb ismeretet és ebből kifolyólag gyorsabb hibajavítást tesznek lehetővé. Ez a gép is, ha nincs HW hiba, akkor nem ellenfél nekem. HW hibával nagyon ritkán találkozom  és az ismertetett módon kezeltem/kezelem. Tudom mit jelent az NBD, megkezdik másnap a javítást és nem befejezik. Soha nem éltem vele, ha pl disk hiba volt kicseréltem (mert volt készleten nálam) és elküldtem nekik cserére a rosszat. Van egy mondásom: másokra várni lúzerség... és eszerint is élek. Persze vannak kivételek, itt a kamu ígéretekre vonatkozik leginkább a kijelentés, illetve a bizonytalanok ígéretéről.

Igazából nincs szükségem a HW raidkártyára és a hotswap funkcióra sem. Tök jó, meg minden, de nekem nem ér annyit, mint amennyi kockázatot ad ezen a szinten. Ugyanis az üzlet bármikor elbír annyi kiesést amennyi egy diskcsere és egy biosban beállítás elvisz. Már egyszer majdnem rábasztam erre a raid kártyára, szintén saját hiba: https://hup.hu/node/170777

Szóval úgy látom, ahogy elbénáztam az elmúlt 25 évben, annál csak jobban fogom csinálni a következőt. :) Valakit megbízni több munka nekem, mint megcsinálni és amúgy is ez egy nagyon erős hobbi nálam.

- Nincs sok tapasztalatom Linux alatti RAID vezérlő kezeléssel és mivel tipikusan virtuális gépben futnak a Linuxok, mdadm is csak ritkán használatos. Most kellett egy speciális Linuxot csinálni, ahol mdadm-ot kellett használni, ide olyan kártya kellett, ami átváltható HBA módba. Mint kiderült, ez nem feltétlenül annyira triviális, mint gondolná az ember, HPE vezérlőknél kacifántokra lehet szükség. Dell simább ügynek tűnt, az lett, működik, ahogy kell. Ezt csak azért írom, mert ha elszáll a vezérlő, attól még lehetnek nehézségek. Ha érdekel szkript, ami automatikus rebuild-et csinál mdadm-mal, kicsit pofozom még és megosztom.

- Továbbra sem értem, miért nem tetszik a hardver raid, cache-eléssel kemény teljesítmény előnye tud lenni.

- "másokra várni lúzerség... és eszerint is élek." - gondolom akkor teljes cseregéped van. Lehet garantált támogatást is venni, ez talán nem kamu ígéret kategória. Üzleti szempontból az is lúzerség, ha te foglalkozol minden vacakkal és nem delegálsz.

- A Drac is tud értesítést küldeni hardver hibáról.

- Én biztos nem Linuxot tennék a vasra, hanem ESXi-t és abba Linuxot, sokkal rugalmasabb, vason belül is hatékonyabban tudsz hálózati szeparációt csinálni. Ekkor persze kompatibilis vezérlő kell, de ez nem szokott gond lenni normálisabb darabok esetén.

Nem számítottam másra.

Ezért sem értem, hogy például ez a hardver bizgerálás, fb-skodás miért fontos számodra. Nyugodtan tudnál egy még racionális keretek között normálisan működő infrastruktúrát csinálni, vagy akár betenni mindent egy felhőbe, tartalékrendszer másik felhőben, netán magadnak is lemented az adatokat, hogy még nagyobb kataklizma esetén is meg legyen a webáruházad.

Informatikailag sokkal izgalmasabb feladat, mint raid vezérlőkkel és merevlemezekkel vacakolni.

Sztorizni is érdekesebb szerintem, mint azt újságolni, hogy robogtál vissza az expó térre.

Szoptam már be jogilag ilyen dolgokat. Nem is egyszer. Attól jobban félek. Emiatt a saját hardver. 
Ha megoldható lenne, nekem az is megfelelne, hogy dedikált és független n x 100 mbit jön a telephelyemre és akkor nem kell sehová sem rohangálnom. Helyem van neki. 

Azért látod fillérbaszásnak, mert nem most vettem ezeket az eszközöket. A legtöbb eszköz túl sok a feladatra így is. Nagyon másként közelítjük meg azt látom. Mondok egy példát, amiben összehasonlítok egy itt elhangzott megoldást.

a)1 szerver  by Oregon
b)2 szerver 1 HA proxy by nemtudomki

A második esetben a leállásra pont ugyanannyi esélyem van, adatvesztésre négyzetesen kevesebb. Cserébe a második esetben a szopólottón 3x annyi a szelvényem van, 3x annyi költségért, 3x annyi munkával.
Kérdés: Ha minden évben van átlag 6 óra leállás (nincs) annak költsége fedezi-e a ráfordítást?
TFH: Igen. Akarok-e több problémát több költségért? => Nem.
TFH: Nem. => Nem

Az a baj, hogy jó így nekem. Ennek oka, hogy az R310-el kétszer szoptam, mindkettő alkalommal a Raidkártya és tudásom inkompatibilitása miatt. Raidkártya kiiktatva, én maradok. Ha nem lett volna ez a kártya, akkor így 25 év után még mindig semmit sem tudna itt senki arról, mit is csinálok, mert nem lett volna esemény. 

Szóval más megoldást választok. Idő mire felépítem. Lesz benne VPS is "kihasználatlanul".

 

Szoptam már be jogilag ilyen dolgokat.

Erről tudnál részletet vagy akár általános információt megosztani, milyen jellegű volt a probléma?

Azért látod fillérbaszásnak, mert nem most vettem ezeket az eszközöket.

Nem azért, hanem azért, mert kvázi lényegtelen szempont alapján közelíted meg a kérdést és olyanra is sajnálod a pénzt, amire nem kellene, nevezetesen normális garanciára vagy arra támaszkodni. Azt simán el tudom fogadni, hogy bizonyos mértékű költségnövekedésnek nem lenne számodra kézzel fogható haszna, például 2 szerver esetén. Nagyobb mértékű költségnövekedést pedig nem szeretnél, ezt tiszta sor.

Van ügyfél, ahol egyetlen szerveren futnak a szolgáltatások (több tucat felhasználó), de jobb garancia szolgáltatás van rá (nem az én döntésem: én felkínálom az opciókat költséggel kockázattal, ügyfél dönt, én elfogadom; olyat nyilván fel sem hozok, amit nem tudok elfogadni). Olyan is van, ahol egyetlen szerver NBD-vel, de ott jelentősen kisebb a hatása a szerver leállásának, mint nálad.

R310-el kétszer szoptam, mindkettő alkalommal a Raidkártya és tudásom inkompatibilitása miatt

Nekem az jön le, hogy a vinyó rakosgatás a hobbid :-)

Alaplap hiba esetén a lemezeket átpakolod egy másik szerverbe? Javítás után vissza? Itt nem lehetnek gondok? Ezt akkor is megcsinálod a közgazdásszal, ha éppen Olaszországban vagy, esetleg rosszabb kommunikációs helyen? Például udev-ben konzolon átírja a hálózati kártya dolgokat? Persze le lehet ezeket dokumentálni droid szinten (pl vim :wq mélységben), tény, csak ez nem 1-2 órás munka. Nekem az a tapasztalatom, hogy mindig lehet egy apróság, amire nem gondol az ember, például a dokumentálás óta frissült a rendszer és máshogy történnek a dolgok, és akkor a történelem megismétli önmagát. Elvégre ez a történelem természete... :-)

Az elmúlt 25 évből vettem.

Jelen esetben néhány konkrét példa:
- ha összeomlik az operációs rendszer (kicsi az esély rá Linux esetén, de nem zárható ki), könnyebb VM szintű mentésből visszaállni
- ha másik raid tömbre/gépre szeretne áttelepülni, sokkal egyszerűbb, gyorsabb, kockázatmentesebb a migráció
- mint fentebb is írtam egy gépen belül is szegmentálni tudja a hálózatát
- nagyobb frissítés előtt pillanatkép lehetőség
- könnyen tud tesztkörnyezet létrehozni a VM klónozásával, pl. frissítést szeretne tesztelni az élesen
- db-t és alkalmazást másik rendszerbe teheti (nem feltétlenül van jelen esetben előnye, de nem zárható ki)
- egyszerű és biztonságos konzol szintű hozzáférés (Drac publikus neten sem egy egészséges felállás, bár tény, hogy fizikai szerveren is megoldható lenne VPN mögé tenni), főleg ha tényleg X-et használ (bár őszintén szólva nem sok óra X server tapasztalatom van VM konzolon)
 

Amiről te beszélsz most, az a virtuális gépekkel megtámogatott vs. bare metal architektúra.

Közben fent arról írsz, h a host gépen linux helyett vmware legyen.

 

Az első AFAIK fel sem merült, a jelenlegi infrája is VM-eken van. Vagy nem olvastam vmi részletet. Így nem értem, h jön ez ide.

VPS-t említ, valóban, de hogy őszinte legyek én nem kínlódnék mással, mint ESXi. Nem tudom, éppen milyen technológiát használ, lehet, hogy a fent leírtak jó része ott is alkalmazható, de lehet, hogy nem. Az ESX(i) 20+ éve piacon van, bizonyított, nincs vele különösebb szívás, legalábbis az én ~15 éves tapasztalatom szerint.

Sokan hívják a VM-et VPS-nek.

A többit én úgy értelmezem, h nem értesz a linux-hoz.

 

> Én biztos nem Linuxot tennék a vasra, hanem ESXi-t és abba Linuxot, sokkal rugalmasabb

Ez a kijelentés ebben a formában óriási tévedés, az ellenkezője igaz. Ha a hoston is egy standard kinux van, akkor a rendszer rugalmasabb.

 

Azzal a felállással általában (nem mindig) egyetértenék, h érdemes virtualizálni vmilyen technológia segítségével és az könnyebbé teszi az ember életét.

Csak hasonló kijelentés nem volt.

 

 

ps.: BTW te nem sales vagy?

A többit én úgy értelmezem, h nem értesz a linux-hoz.

Ez egy erőteljesen relatív fogalom. Biztos többen/sokan vannak itt a HUP-on, akik nálam jobban értenek hozzá. De azt nem jelenteném ki, hogy nem értek hozzá és nem nagyképűségből. Ha tudsz valami jó hozzáértés mérőt, szívesen belövöm rajta magamat, ezzel akár egy szavazást is indíthatsz a címlapon, biztos érdekes lenne.

Ez a kijelentés ebben a formában óriási tévedés, az ellenkezője igaz. Ha a hoston is egy standard kinux van, akkor a rendszer rugalmasabb.

Kérdés, hogy mit tekintesz a rugalmasság fokmérőjének és mi a célod.

Ha a rugalmasságot úgy tekinted, hogy milyen műveleteket tudsz a fizikai operációs rendszeren végezni, akkor való igaz, hogy a Linux rugalmasabb (sokkal rugalmasabb, például ESXi-re nem fogsz VPN szervert tenni, de nincs is rá szükség, sőt, ne is legyen). De a tapasztalatom az, hogy felteszed az ESXi-t és nyugalmad van. Amit tipikusan csinálni szeretnél, azt könnyen meg tudod csinálni, nem kell barkácsolni, működik. Vannak hozzá jó szoftverek, amik hasonlóan megbízhatóan, egyszerűen működnek, tipikusan nem reszeléssel megy az idő.

Azzal a felállással általában (nem mindig) egyetértenék, h érdemes virtualizálni vmilyen technológia segítségével és az könnyebbé teszi az ember életét.

Csak hasonló kijelentés nem volt.

Mikor célszerű virtualizálni? Ez nagy mértékben függ attól, hogy kinek mi a szakterülete. Ha (általános) üzleti alkalmazásokat nézek, én én azt látom, hogy néhány speciális esetet kivéve mindig érdemes virtualizálni. Jelen témában lényegében egy webshop/ERP van tudomásom szerint, ami ebbe a körbe esik.

ps.: BTW te nem sales vagy?

Olyan értelemben igen, hogy árulok portékát, de olyan értelemben nem, hogy csak árulnék és lenne egy külsőleg meghatározott célom, hogy adott időszakban milyen forgalmat kell teljesítenem. Továbbá azt árulok, amit jónak látok, nem azt, amit kell, nyitott vagyok az újra.

> Ha tudsz valami jó hozzáértés mérőt

Mondj 1-2 üzemeltetési problémát a közelmúltból, amit te hands-on megoldottál.

> Ha a rugalmasságot úgy tekinted, hogy milyen műveleteket tudsz a fizikai operációs rendszeren végezni, akkor való igaz, hogy a Linux rugalmasabb (sokkal rugalmasabb, például ESXi-re nem fogsz VPN szervert tenni, de nincs is rá szükség, sőt, ne is legyen). De a tapasztalatom az, hogy felteszed az ESXi-t és nyugalmad van.

 

A rugalmasságot állítod szembe a megbízhatósággal. Különböző fogalmak.

Ráadásul ugy allitod be a vw-s feature-öket, mintha azok egy linux host esetén nem lennének meg.

Engem kifejezetten zavar, h egyoldalúan nyilatkozol. Ezért is van az, h azt sejtem, nem értesz a linuxhoz.

 

> Mikor célszerű virtualizálni? Ez nagy mértékben függ attól, hogy kinek mi a szakterülete.

Nem kellene. h függjön tőle, ha egyébként az illetőnek megvannak az alapok a különböző megoldások irányába (pl. virtualizáció, backup, automatizáció).

> olyan értelemben nem, hogy csak árulnék

Ahogy fent írtam, milyen linuxos üzemeltetési problemakat oldottál meg hands-on a közelmúltban?

Mondj 1-2 üzemeltetési problémát a közelmúltból, amit te hands-on megoldottál.

mdam alatt kicserélsz egy merevlemezt: bedugod az újat, particionálja, felveszi a raid tömbbe, mindez konfigurációs fájlból egyszerűen paraméterezve.

systemd alatt indításkor/leállításkor szkript futtatása

Te hova sorolod magadat, milyen problémákkal foglalkozol, miket oldottál meg?

A rugalmasságot állítod szembe a megbízhatósággal. Különböző fogalmak.

Valóban keveredtek a dolgok, a rugalmasságot a virtualizáció előnyeire gondoltam elsősorban, amit az ESXi egyszerűen biztosít.

Egyoldalúan nyilatkozok: ESXi-re érted? Lehet, ennek egyértelmű oka van, nagyon bevált, hatékony.

Sales: 2007-ben szereztem az első VCP-met (VMware), konfigoltam már FC, FCoE (ebből mondjuk csak egyet), iSCSI hálózatot, Fujitsu Storage Cluster konfiguráció (talán első az országban), NetApp FlexClone-re épülő alkalmazás Java-ban, Veeam "orchestrator" c#-ban, ez néhány dolog az, ami hirtelen eszembe jut és nem igazán jellemző egy értékesítőre. A teljes lista jóval hosszabb, nem gondolom, hogy műszakilag szégyenkeznem kellene a HUP-on.

> Valóban keveredtek a dolgok, a rugalmasságot a virtualizáció előnyeire gondoltam elsősorban, amit az ESXi egyszerűen biztosít.

 

Nem tudom, h hova gondoltad, viszont a linux vs. esxi host témához irtad.

 

> Egyoldalúan nyilatkozok: ESXi-re érted? Lehet, ennek egyértelmű oka van, nagyon bevált, hatékony.

 

Nem lehet, h azért nyilatkozol így, mert csak ahhoz értesz (feltételezem értesz)? Megint leírom. Elkezdted promótalni az ESXi-t olyan szöveggel, mintha a feltüntetett előnyök nem lennének meg azoknál a megoldásoknál, ahol linux a host.

Neked ez nem jelent problémát?

 

> mdam alatt kics erélsz egy merevlemezt: bedugod az újat, particionálja, felveszi a raid tömbbe, mindez konfigurációs fájlból egyszerűen paraméterezve.

> systemd alatt indításkor/leállításkor szkript futtatása

IMO junior szintű a linux ismereted.

 

> Te hova sorolod magadat, milyen problémákkal foglalkozol, miket oldottál meg?

 

Megterveztem egy rendszer átalakítását olyanra, h a szervereken a virtuális gépek automatikusan legyenek mentve, a konfigurációjuk központilag legyen kezelve, iso27k compliant legyen, itt-ott HA legyen néhány service, rapid point in time recovery, monitoring, menet közben ubuntu verzió upgrade, security hardening, low effort server install (nem full automatikus), virtualizáció technológia váltás, performance tuning egy élő, kritikus rendszeren. 6 dc (nem nagyok), gőzöm nincs mennyi host (100 alatt jóval). A tervezés és a kivitelezés is csapatban, én voltam a teamlead (már eljöttem), talán nem volt olyan komponens, amibe nem nyúltam bele.

Azért ezt hoztam fel, mert releváns a temaba vágó.

[Közben rájöttem, felesleges volt leírnom, irreleváns abból a szempontból, h mit írtál te és annak mi az értelme.]

 

A te commentedből viszont nem derül ki még mindig, h miért ajánlod inkabb az esxi-t a linux-szal szemben (ami jelenleg működik nála).

Azért érdekes a sales-es vonal nálad, mert egyelőre csak a sales-es szöveget látom tőled. A fenti autósra, faszán tud gurulni a kocsi, 9s alatt van 100-on, usb csatlakozás is van benne és isofix, soha nem hagy az út szélén (mondod te) és ez nagy rugalmasságot ad neki.

Nem lehet, h azért nyilatkozol így, mert csak ahhoz értesz (feltételezem értesz)? Megint leírom. Elkezdted promótalni az ESXi-t olyan szöveggel, mintha a feltüntetett előnyök nem lennének meg azoknál a megoldásoknál, ahol linux a host.

Nálam azért van az ESXi fókuszban, mert teszi a dolgát, hatékonyan. Nincsenek vacakolások, reszelések, VM fut. Vannak hozzá megfelelő szoftverek, amiket szintén nem kell reszelni, elvárások teljesülnek. Hosszú távon.

Linux esetén nem tudok ilyen robusztus környezetről, de ha van, megoszthatnád, hogy miket használsz és javasolsz alternatívának, ami kicsitől nagyig kielégíti az igényeket. Persze nem törvényszerű, hogy kicsi és nagy ugyanazt használja, de egyszerűbb, ha kevesebb technológiát kell követni, üzemeltetni.

Úgyhogy nem, nem jelent problémát. Vannak helyzetek, amikor tudok alternatívákat, akkor elmondom azokat is, aztán az illetékes választ ízlése szerint.

IMO junior szintű a linux ismereted.

A systemd tényleg nem egy atomfizika, de legutóbbi, ezért írtam, azt azért megnézném, hogy miként rázod ki a kisujjadból az automatikus md újraépítést (legalábbis feltételezem, hogy jóval fölém helyezed magadat, bár én nem látok hatalmas szakadékot, mert amit leírtál, az alapvetően nem Linux specifikus, legfeljebb az Ubuntu upgrade). Nem állítom, hogy expert szint, de nem is junior.

irreleváns abból a szempontból, h mit írtál te és annak mi az értelme.]

Érdekes, ha a kérdésedet sem tudod értelmezni: arra voltál kíváncsi, hogy echte értékesítő vagyok-e. Ha nem derült ki ebből, hogy nem vagyok az, sajnálom.

Azt viszont nem derül ki a leírásodból, hogy te milyen virtualizációt tudsz javasolni, ami hosszú távú stabil technológia, ha már ennyire zavar az ESXi ajánlása. Ha leszel oly szíves és megosztod, akkor kérlek mentő és replikáló szoftvereket is osszál meg hozzá, becs szó használni fogom, ha valóban olyan és adódik rá alkalom, sőt, itt is fogom említeni alternatívaként.

egyelőre csak a sales-es szöveget látom tőled

Tekintve, hogy alapvetően elvekről beszélünk, nehéz részletekbe belemenni. Egyébként azért is említem neki az ESXi-t, mert a Proxmox nem szimpatikus számára, illetve 25 évre tervez.

Neked például mi a véleményed a szerver garanciáról, hw vs sw raidről?

> Nálam azért van az ESXi fókuszban, mert

Még mindig nem érted v. nem akarod érteni.

Nem az a kérdés, h az esxi miért igen, hanem a linux miért nem.

Az esxi-hez leirtad a whitepapert kivonatosan, aztán csókolom.

Írnál 1-2 szót esetleg arról is, h miért ne? Biztosan vannak hátrányai is.

 

> Vannak helyzetek, amikor tudok alternatívákat

Na végre. Leírtad implicit, h nem értesz (eléggé) hozzá.

 

> replikáló szoftvereket

Ilyet nem fogok tenni, mivel nem sales, hanem engineer vagyok. Nem keresek az sw-n, hanem megoldást szallítok.

> fölém helyezed magadat, bár én nem látok hatalmas szakadékot, mert amit leírtál, az alapvetően nem Linux specifikus

Nem helyezem *föléd* magad. OMG, mintha erőből le akarnálak nyomni. Mutass valid érveket és szívesen veszem.

Nálad linuxban valószínűleg sokkal nagyobb a tapasztalatom. Csakhogy ahogy később írtam, totál irreleváns, h milyen tapasztalatom van nekem, semennyire nem befolyásolja azt, h te mit és hogyan ajánlasz.

Írod, h esxi ellen beszélek. Ez nem igaz, lehet az egy csodálatos és jó megoldás (amúgy sok szempontból az és amennyire ismerem, bizonyos esetekben a legjobb), ha nem arra van szükség és ha irreleváns érvekkel tamasztod ala (pl. flexibility vs. reliability).

 

Címszavakban szerintem az OP-nek kvm és lxc az optimális megoldás lxd hypervisorral.

Én nem replikalnek, hanem berelnem a hw-t és arra tamaszkodnék, többet ér vele. Ha megis, akkor megoldanam custom scripttel (nekem van rá saját).

Hogy miért? Mert leírta világosan, h kerülni akarja a vendor lock-int, ami egy nagyon ésszerű lépés a megadott rendszer méretben.

Alternatívaként a proxmox is jó lehet, amikothasznaltam, működött kisebb zökkenőkkel (és izgulással) és ezért kerülném.

Itt esxi-t sose használnék se én, se nem ajánlanám, mivel nem ért hozza, tanulhatna meg 1 új ökoszisztémát, nem éri meg a befektetést (btw lattam esxi-t megallni, meg hibázni és olyankor nem volt más, mint a pingvinezés, ennel a linux 10000x több lehetőséget ad, ami kiemelten fontos az OP-nek).

Nem az a kérdés, h az esxi miért igen, hanem a linux miért nem.

Pedig leírtam: Linux alatt nem ismerek olyan alternatívát, ami az eddigi elvárásokat (pontosabban elvárásaimat, amik tipikusan üzleti elvárásokkal is találkoznak) teljesítené.

Hátránya? Régi processzorokat kezdik nem támogatni, de mivel most vett új szervert, ezért ez nem releváns, a virtuális gép kompatibilitást nem befolyásolja. Másik hátránya, hogy a grafikus felület miatt sokan azt hiszik, tudják, mit csinálnak, holott nem, leginkább hálózatilag tudnak rémálmok keletkezni. Egyesek számára hátrány, hogy pc-n nem feltétlenül fut, ez számomra irreleváns.

Ilyet nem fogok tenni, mivel nem sales, hanem engineer vagyok. Nem keresek az sw-n, hanem megoldást szallítok.

Akkor most miről beszélünk? Egy megoldás komponensekből áll, ekkora erővel te még annyi konkrétumot sem közölsz mint, én. Ha építészek beszélgetnek, óhatatlanul felmerülhetnek gyártói nevek. A mérnök abból főz, ami a rendelkezésre áll.

Nem helyezem *föléd* magad.

Dehogynem, "junior", "sales-es vagy".

Egyébként érdekelne, hogy szerinted mik merülnek fel egy "hot md" során, a te tapasztalatodra reflektálva mit értesz "menet közben ubuntu verzió upgrade" alatt.

Csakhogy ahogy később írtam, totál irreleváns, h milyen tapasztalatom van nekem, semennyire nem befolyásolja azt, h te mit és hogyan ajánlasz.

Ha ismered az ESXi képességeit, lehetőségeit, megoldás szállító mérnök vagy, nyugodtan leírhattad volna, hogy van ez is, ezzel és azzal, szerinted legalább olyan jó a célra és nincs gyártó függőség, olcsóbb, nyílt pályán marad. De te szakmai érvek helyett inkább azt választottad, hogy megpróbálsz jelen szempontból üres értékesítőnek beállítani. Ez nem mérnöki, hanem troll hozzáállás.

kvm és lxc az optimális megoldás lxd hypervisorral

Mentést mivel csinálnád? Van inkrementális VM szintű megoldás? VSS támogatás?

A replikációt nem ezen eset miatt kérdeztem (itt el lett vetve), hanem általában van-e rá megoldás.

Mert leírta világosan, h kerülni akarja a vendor lock-int, ami egy nagyon ésszerű lépés a megadott rendszer méretben.

Alapvetően én is szeretem a nyílt rendszereket, de még jobban a stabil megoldásokat. Néha felül kell/lehet revidiálni bizonyos álláspontot. Ez nyilván rám is vonatkozik, ha pl. LXD beválhat.

ESXi hiba: igen, ritkán előfordul, de tényleg nagyon ritkán. Szerintem nem több, mint mással, sőt. Az 10000x több lehetőséget nem tudom értelmezni.

A hw vs sw raid témára nem reagáltál, mint mérnök, illetve a garanciára sem. De tőlem hiányolod a nem sales-es megnyilvánulást.

A Proxmox tapasztalatot köszi.

> Hátránya

Én írok még.

Vendor lock-in, ezentúl csak azzal tudsz matatni guesteket.

Ahhoz kell alakítani a környéket is, observability, backup, csere hw, jövőbeni hw.

Nincs flexibilitás, h szabadon cserelgesse a hw elemeket (tönkremegy vmi? szopás, raid vezerli upgrade? szopás:), fizetheti a licenszeket jobbra-balra (monitoring... bár ez lehet, h most is cloud, backup sw, esxi licensz).

Ha nem működik vmi? Szopás v. szerencsés esetben van fix, de belenyúlni tuti nem fog.

 

> Dehogynem, "junior", "sales-es vagy".

Leírtam, miért érdekesek. Azt is (többször), h miért irreleváns az én tudásom.

> Egyébként érdekelne, hogy szerinted mik merülnek fel egy "hot md" során, a te tapasztalatodra reflektálva mit értesz "menet közben ubuntu verzió upgrade" alatt.

Nem tudom, mi a hot md.

Az Ubuntu upgrade az, h van 1 verzió egy architektúrán és az architektúra váltás közben változik az Ubuntu verzió is.

 

> Mentést mivel csinálnád? Van inkrementális VM szintű megoldás? VSS támogatás?

Igen. Én zfs-sel (arra van megoldásom), btrfs-re is tuti van hasonló és feltetelezem, sima kvm-re is tuti (borg első pillantásra tudja, de dunno, nem használom a borgot).

> De te szakmai érvek helyett inkább azt választottad, hogy megpróbálsz jelen szempontból üres értékesítőnek beállítani. Ez nem mérnöki, hanem troll hozzáállás.

 

A sales "kiüresítését" legfeljebb te magad csinálod most. Te allitod be alsóbbrendűnek és üresnek.

A sales nekem értékes, ha jó. Van jó sales-es kapcsolatom.

Sőt, ettől a thread-től még te is lehetsz az. ennyi alapján nem ítélkezem.

Azt nem gondolom trollkodásnak, h vannak problémáim az ajánlásodnak és azt le is írom. Szerintem ezen a fórumon úgy beállítani egy vw-s megoldast, mintha az nem lenne meg egy masik architektúrán, az inkorrekt dolog. Erre raktam fel keresztkérdéseket, amit te sajnos személyesnek és támadásnak vettél.

 

> Alapvetően én is szeretem a nyílt rendszereket, de még jobban a stabil megoldásokat. Néha felül kell/lehet revidiálni bizonyos álláspontot. Ez nyilván rám is vonatkozik, ha pl. LXD beválhat.

Szuper, akkor mondd azt, h az esxi kiforrott és így leellenőrizhetően *megbízható* technológia, bizonyított már sok hasonló környezetben, a segged alá adják a megoldást (szinte) ootb annak az árán, h be szorítanod magad egy keretbe (épp asszem ebben a topicban volt erre egy analogia sw fejlesztés keretrendszerben témával). Ezt így aláírnám.

Azt is, h ha vki azt mondja, h az LXD pl. kevésbé ismert, talán többet változik is, farigcsalósabb, összességében meg nincs iránta akkora bizalom. Proxmox dettó. Különösebben nem hat meg, vvali állítás.

> Az 10000x több lehetőséget nem tudom értelmezni.

Ha linux-on van kvm, akkor az image ott van, akár cli-ből el tudja indítani.

Ha lxc-t hasznal, akkor meg bele is mászhat és úgy és oda másolja az adatot, ahova akarja (másik ct, másik gep stb.) Vannak lehetőségei.

ESXi esetén ez kötöttebb.

Dettó sw raid, tönkremegy a hw? Az md raid, btrfs, zfs pont ugyanúgy működik A és B gépen is.

Emiatt nem kell fájjon a feje, h észben tartsa a kompatibilitási listát. Ergo elrontani sem lehet (amiről azt sem tudja, h elrontható, azaz tutira el is fogja rontani).

> A hw vs sw raid témára nem reagáltál, mint mérnök, illetve a garanciára sem. De tőlem hiányolod a nem sales-es megnyilvánulást.

 

Azt nem értem, mi a relevanciája ide v. mi a kérdés?

Vendor lock-in, ezentúl csak azzal tudsz matatni guesteket.

Ha arra gondolsz, hogy VMFS-en levő cuccot mással nem érsz el, akkor ez egyrészt igaz (de csak részben, lásd https://packages.ubuntu.com/kinetic/vmfs6-tools, bár még soha nem használtam), másrészt soha nem volt rá szükségem. Hallottam már olyanról, akinek volt rá szüksége, de ez nagyon régen volt.

Ahhoz kell alakítani a környéket is, observability, backup, csere hw, jövőbeni hw.

Ha normál gyártótól veszel szervert, akkor ez egyáltalán nem probléma. A mentő megoldások teljesen jók rá, ezt sem értem, miért probléma. Ha nincs normális ingyenes megoldás én nem sajnálom a jó szoftver árát, bőven behozza az árát a farigcsálásokhoz képest.

Nincs flexibilitás, h szabadon cserelgesse a hw elemeket (tönkremegy vmi? szopás, raid vezerli upgrade? szopás:), fizetheti a licenszeket jobbra-balra (monitoring... bár ez lehet, h most is cloud, backup sw, esxi licensz).

Volt már RAID vezérlő upgrade ESXi alatt, köszöni, jól működött. Nem látom, mivel lehet probléma. Esetleg hálókártya cseréjével (elmásznak a portok), de mintha olyan is lett már volna, ezzel Linux alatt kis kell foglalkozni.

Licenc: egyrészt van ingyenes, másrészt van Essentials kisebb környezetre, nagyobb környezet esetén pedig tényleg nem tudom, milyen alternatívát tudsz felhozni Hyper-V-n kívül. Régebben voltak Xen alapú megoldások, nem tudom, azok most miként állnak, de most már bőven lett volna ideje más megoldásoknak is kinőni mellette, mégsem történt meg, úgyhogy nagy gond nem lehet az ESXi-vel.

Ha nem működik vmi? Szopás v. szerencsés esetben van fix, de belenyúlni tuti nem fog.

Egyre inkább azt látom, hogy Te valami barkács környezetben használsz/használtál ESXi-t, nagyon minimális gond szokott lenni vele.

Nem tudom, mi a hot md.

Amit írtam: bedugod az új merevelemezt és felveszi md-be. Ha sok md-t használtok, javaslom egy juniornak kiadni feladatnak, csodálom, hogy eddig nem merült fel és mindig kézzel faragtátok bele a rendszerbe az új lemezt.

Az Ubuntu upgrade az, h van 1 verzió egy architektúrán és az architektúra váltás közben változik az Ubuntu verzió is.

Ki tudnád fejteni bővebben? Az architektúra váltás az én olvasatomban pl. Intelről ARM-ra.

Igen. Én zfs-sel (arra van megoldásom), btrfs-re is tuti van hasonló és feltetelezem, sima kvm-re is tuti

Windows-t is tudsz inkrementálisan VM szinten menteni? LXD pillanatképnél nem láttam VSS integrációs opciót.

"feltételezem" - én ESXi esetén nem feltételezem, hanem tudom, azért ajánlom.

Azt nem gondolom trollkodásnak, h vannak problémáim az ajánlásodnak és azt le is írom.

Nem érvekkel kezdtél, hanem kompetenciámat kérdőjelezted meg, ez summázza a hozzáállásodat.

Szerintem ezen a fórumon úgy beállítani egy vw-s megoldast, mintha az nem lenne meg egy masik architektúrán, az inkorrekt dolog.

Mi nincs meg másik architektúrán? Ismételni tudom csak magamat: miért nem az LXD megírásával kezdted? Engem spec őszintén érdekelne is, mik a lehetőségei, korlátai, de elég pongyolán fogalmazol mérnöki elvárásaid ellenére.

Szuper, akkor mondd azt, h az esxi kiforrott és így leellenőrizhetően *megbízható* technológia, bizonyított már sok hasonló környezetben

Ha nem is szó szerint, ez így kb elhangzott szerintem.

Azt is, h ha vki azt mondja, h az LXD pl. kevésbé ismert, talán többet változik is, farigcsalósabb, összességében meg nincs iránta akkora bizalom.

Tekintve, hogy sose használtam LXD-t, nem tudok róla írni. Ha valami farigcsálósabb, az én olvasatomban azt jelenti, hogy több vele a szívási lehetőség/kockázat, több idő megy rá, ami akár drágább, mint egy ingyenes vagy Essentials ESXi licenc, amit felteszek és el van felejtve a következő frissítésig.

Ha linux-on van kvm, akkor az image ott van, akár cli-ből el tudja indítani.

Újdonságot árulok el azzal, hogy ESXi-nek is van CLI-je és CLI-ből is tudsz VM-et indítani?

Ha lxc-t hasznal, akkor meg bele is mászhat és úgy és oda másolja az adatot, ahova akarja (másik ct, másik gep stb.) Vannak lehetőségei.

ESXi esetén ez kötöttebb.

Ez tényleg kötöttebb, de eddig nem merült fel ez az igény. Talán mert működik?

Dettó sw raid, tönkremegy a hw? Az md raid, btrfs, zfs pont ugyanúgy működik A és B gépen is.

Ha tönkre megy a hw, akkor ki kell cserélni. Itt sem értem a problémádat, mi köze md-hez és zfs-hez.

Az régen rossz, ha nem érted a hw vs sw raid és garancia kérdést. Ez is azt mutatja, hogy csak troll módon belekotyogtál. De a reakcióid alapján valószínűleg nem feltétlenül garanciális szerverekkel dolgozol, hanem probléma esetén barkácsolsz, ami sok mindent megmagyaráz.

> Ha arra gondolsz, hogy VMFS-en levő cuccot mással nem érsz el,

Részben. Nemcsak az image a lényeg, hanem annak a tartalma, ill. az image használhatósága.

> Ha normál gyártótól veszel szervert,

Ez egy a a korlátozó dolgok közül. Vkinek fáj, masnak kevésbé, az tuti, h mindenképp adott.

 

>  Ha nincs normális ingyenes megoldás én nem sajnálom a jó szoftver árát, bőven behozza az árát a farigcsálásokhoz képest.

 

Én a költségektől és a kockázatoktól teszem függővé.

> Amit írtam: bedugod az új merevelemezt és felveszi md-be. Ha sok md-t használtok, javaslom egy juniornak kiadni feladatnak, csodálom, hogy eddig nem merült fel és mindig kézzel faragtátok bele a rendszerbe az új lemezt.

Akkor nem értem, miért irtad egy mondatba az ubuntuval. Mi a kérdés vele kapcsolatban?

Mindenesetre a leírásod alapján nem látom a nagy hozzáadott értéket nekem. Fel sem merült nálam sose a hiánya.

Amúgy ha jó, akkor publikáld és promótald:)

 

> Volt már RAID vezérlő upgrade ESXi alatt, köszöni, jól működött.

Az megvan. miből indult ez a topic?:)

 

>  nagyon minimális gond szokott lenni vele.

 

Ahogy az OP kifejtette, az épp eléggé fáj neki. Az én esxi-s gebaszom már jó rég volt amúgy, arra nem alapoznék semmit, az elvről beszélek. Attol a gebasztól még simán választanám megoldásként.

> Az Ubuntu upgrade az, h van 1 verzió egy architektúrán és az architektúra váltás közben változik az Ubuntu verzió is.

 

Nem processzor, hanem más, pl. virtualizáció, network stb.

 

> Windows-t is tudsz inkrementálisan VM szinten menteni? LXD pillanatképnél nem láttam VSS integrációs opciót

 

Igen. Amúgy az az a szitu, windows guestek, amikor az esxi inkább preferált. Ill. adott esetben bevonnék mást, ha igényli a helyzet.

 

> Nem érvekkel kezdtél, hanem kompetenciámat kérdőjelezted meg, ez summázza a hozzáállásodat.

 

Azzal kezdtem, h mire alapozod és te válaszoltad lenyegebeny, h azért, mert kompetens vagy. Nekem meg annyi nem elegy, h becszó.

 

> Mi nincs meg másik architektúrán? Ismételni tudom csak magamat: miért nem az LXD megírásával kezdted? Engem spec őszintén érdekelne is, mik a lehetőségei, korlátai, de elég pongyolán fogalmazol mérnöki elvárásaid ellenére

 

Mert nem akartam nyomni az n+1-dik javaslatot (talán a harmadik), mert nincs jelentősége. alehetne valószínűleg még 22-t. Az elv a lényeges, h amit vki ajánl az vajon a usernek mennyire szolgalja az érdekét.

 

Az lxd-ről irhatnék is (hideget-meleget), ha nem lennél ellenséges. Így se kedvem nincs, se helyét, se okát nem latom.

> Ha nem is szó szerint, ez így kb elhangzott szerintem

 

Olyan kontextusban, mintha más nem adna kielégítő megoldást. Persze ez szubjektív, nekem így jött le.

> Ha valami farigcsálósabb, az én olvasatomban azt jelenti, hogy több vele a szívási lehetőség/kockázat,

És a lehetőség is. Megintcsak, mennyibe kerül elérni a célt és milyen kompromisszumot kell érte fizetni. És nemcsak $$ a kérdés.

 

> Újdonságot árulok el azzal, hogy ESXi-nek is van CLI-je és CLI-ből is tudsz VM-et indítani?

Úgy értem, h az alap megoldástól függetlenül. Elmasolod mashova és 'kvm ....'

 

> Talán mert működik

Amikor, akkor igen:)

 

> Ha tönkre megy a hw, akkor ki kell cserélni. Itt sem értem a problémádat, mi köze md-hez és zfs-hez.

> Az régen rossz, ha nem érted a hw vs sw raid és garancia kérdést. Ez is azt mutatja, hogy csak troll módon belekotyogtál. De a reakcióid alapján valószínűleg nem feltétlenül garanciális szerverekkel dolgozol, hanem probléma esetén barkácsolsz, ami sok mindent megmagyaráz.

 

Kérdést akkor lehet megérteni és megválaszolni, ha felrakják.

Dolgozok mindenféle szerverrel. Garis. brand, nobrand. bérelt, aws stb

 

 

Szerintem zárjuk le itt. Nincs már szakmai szöveg érdemben IMO

Részben. Nemcsak az image a lényeg, hanem annak a tartalma, ill. az image használhatósága.

Ki tudod exportálni és tudod használni, elsősorban OVF-be, de a VMDK eléggé univerzális formátum.

Ez egy a a korlátozó dolgok közül. Vkinek fáj, masnak kevésbé, az tuti, h mindenképp adott.

Én úgy vagyok vele, ahogy a szakik a Black & Deckerrel: munkára inkább célszerszámot.

Mindenesetre a leírásod alapján nem látom a nagy hozzáadott értéket nekem. Fel sem merült nálam sose a hiánya.

Úgy tűnik szeretsz faragni. Az automatizmus segíti a gördülékeny üzletmenetet. Pl. ha Oregon a közgazdászát küldi kicserélni a lemezt, nem biztos, hogy rá kellene bízni, ha ő nem tud normális net közelben lenni. Nem nehéz olyan hibát véteni, ami adatvesztéssel jár.

Az megvan. miből indult ez a topic?:)

Az megvan, mit rontott el?

> Windows-t is tudsz inkrementálisan VM szinten menteni? LXD pillanatképnél nem láttam VSS integrációs opciót

Igen. Amúgy az az a szitu, windows guestek, amikor az esxi inkább preferált. Ill. adott esetben bevonnék mást, ha igényli a helyzet.

Idézem a kiindulást: "Mivel igény jelentkezett arra, hogy kellene egy Windowsos VPS"

Akkor most mi is a konkrét probléma az ESXi javaslattal?

Az én esxi-s gebaszom már jó rég volt amúgy, arra nem alapoznék semmit

Ahhoz képest folyamatosan azzal érvelsz, hogy probléma esetén mihez kezdesz. Én még közelében nem voltam ESXi-vel olyan problémának, ami elvette volna a kedvemet, tipikusan pöccre mennek a dolgok.

Az Ubuntu upgrade az, h van 1 verzió egy architektúrán és az architektúra váltás közben változik az Ubuntu verzió is.

Nem processzor, hanem más, pl. virtualizáció, network stb.

Csináltál valami fürtözős megoldást, és úgy költözött át? Vagy mi akart a lényeg lenni? Engem komolyan érdekel mind a feladat, mind a megoldás, mi volt a nehézség. Milyen alkalmazások futottak rajta?

Nekem meg annyi nem elegy, h becszó.

Ehhez képest olyan "megoldásokat" javasolsz, írsz, amiket még nem is használtál, "feltételezem". Egyoldalú a követelményrendszered.

Mert nem akartam nyomni az n+1-dik javaslatot (talán a harmadik), mert nincs jelentősége.

Szerintem pedig pont, hogy van jelentősége, én például kifejezetten kíváncsi lennék akár 3 másikra is, ha bevált.

Az lxd-ről irhatnék is (hideget-meleget), ha nem lennél ellenséges. Így se kedvem nincs, se helyét, se okát nem latom.

A hidegre kifejezetten kíváncsi lennék, szerintem Oregon is, ha már ajánlod, hogy mik a hátrányai. Főleg, hogy ESXi esetén belementél és lényegi ellenérvet nem hoztál fel (vendor lockin és hasonlók legfeljebb oss geek szinten érvek esxi esetén, nem üzletileg).

Én ESXi-ről nem sok hideget tudok írni, ezért merem bátran ajánlani.

És a lehetőség is. Megintcsak, mennyibe kerül elérni a célt és milyen kompromisszumot kell érte fizetni. És nemcsak $$ a kérdés.

A mérnöknek az a feladata, hogy a célnak megfelelő megoldást biztosítson. A cél tartalmazza például az elvárásokat (funkcionalitás, kockázat, ...), költségkeretet.

Az én látókörömben sosem merült fel igényként, hogy ESXi alól bizergálni kellene a VM-ben levő fájlokat. Ellenben az folyamatosan felmerül, hogy üzembiztos, egyszerűen üzemeltethető legyen, lehessen menteni, replikálni.

A $$ valóban fontos kérdés, ennek része, hogy mennyi időt kell vele foglalkozni. Ez nemcsak munkaóra miatt lényeges, hanem ha sokat kell nyomogatni, akkor több szakember is kell, amiből tipikusan hiány van.

Úgy értem, h az alap megoldástól függetlenül. Elmasolod mashova és 'kvm ....'

Sima elmásolással valóban nem (bár ebben sem vagyok biztos, mert pl a VirtualBox tud VMDK-t kezelni, még ha nem is szerver oldali megoldás, átmenetileg hasznos lehet), de mint fentebb írtam ki tudod exportálni. De ez megint olyan igény, ami legfeljebb barkács környezetekben merül fel.

Szerintem zárjuk le itt. Nincs már szakmai szöveg érdemben IMO

Én megköszönném, ha behoznál némi műszaki tartalmat, ha már azt hiányoltad. Engem kifejezetten érdekel, hogy LXC tud-e elcsendesített mentést VSS integrációval és megoldható-e virtuális gép szintű inkrementális mentés platform függetlenül. Például van-e tapasztalatod Veeam Agent alapú mentéssel LXD esetén, bár ha már fizetős szoftvert kell behozni, akkor már megint ott tartunk, hogy inkább ESXi.

Milyen problémák vannak/lehetnek LXD-vel, milyen hátrányai vannak (ha már ESXi oldalon elő kellett volna hozni). Mert eddig ott tartunk, hogy becs szóra elhintetted és állítólag hideget azért lehet róla mondani.

De persze könnyebb belekötni a másikba, aztán konkrétum nélkül elkullogni.

> Pl. ha Oregon a közgazdászát küldi kicserélni a lemezt, nem biztos, hogy rá kellene bízni, ha ő nem tud normális net közelben lenni. Nem nehéz olyan hibát véteni, ami adatvesztéssel jár.

Jobb híján. Nem vagyunk sokan, szerencsére. Az alacsony létszám cél nálunk.

Amikor kollégát veszek fel, akkor így kezdődik a listám:
- intelligens
- kedves
- nyugodt
- érdeklődő
- motivált 

Minden más megtanulható.

Emiatt ezekre az emberekre, kb bármit rábízhatok. Hibázni nálam szabad. Egy dolog az elvárás, hogy tanuljon belőle. Ha a hiba gyakori, akkor nekem kell a rendszer újragondolni.

Mielőtt ezt rám vonatkoztatnád. Nyitottam egy rést, amin keresztül megmutattam egy balfaszságot. Páran azt gondoljátok, ahol egy balfaszság van, ott kell lennie többnek, sőt kell lennie egy hatalmas nagy balfaszságnak is. Vagyis az egyről következtettetek a többre. Ha gyakori lenne nálam a balfaszság, akkor szoronganék annyira miatta, hogy a semennyit se mutassak meg belőle. Mint, ahogyan korábban írtam. Más hibájából gyorsabban lehet tanulni, mint abból amit a másik jól csinál.

Többször fikázod a barkácsolást. Nyomod a dobozost. Azok akik anno elkezdtek Linuxozni és megragadta őket, azok nem egy Windows pótlékot találtak meg benne. Hanem tengernyi összeépíthető legokockát. Engem a mai napig ez vonz benne. Számomra nem informatikus az, akinek a telepítés next->next->finish és az üzemeltetés annyi, hogy be tudja kapcsolni a  gépet (figyelni a ledeket :P), és tud szólni a supportnak. Az ügyem kapcsán elkezdtem csinálni egy leírást, hogyan építek fel egy levelező rendszert. Szerintem te a hajadat kitépnéd, hogy közel 10 alrendszer összedrótozásával készül el. Amikor elkezdtem írni, akkor az is szándék volt, hogy más is belekezdjen. Most, hogy a vége felé járok, már látom, hogy ezzel lehet inkább elveszem a kedvét másoknak. Iszonyat sok ismeretet kíván a téma. Ennyit ma már nem hajlandóak tanulni az emberek. A tegyél fel egy Proxmoxot című mondatot olyanoktól hallom mostanában, akik a múlt héten még pincérek voltak. 

Azok akik anno elkezdtek Linuxozni és megragadta őket,

Én is "anno" kezdtem Linuxozni, 95-ben, még most is legózok. Csak a hardver meghibásodások nem tartoznak a kedvenc időtöltéseim közé (és megfelelő felkészültség nélkül nehéz jól csinálni), illetve teljesen más, ha saját magadnak üzemeltetsz, mintha másoknak üzemeltetnél. Ha másoknak üzemeltetsz, akkor vannak elvárások (helyzettől függően eltérőek).

Az ügyem kapcsán elkezdtem csinálni egy leírást, hogyan építek fel egy levelező rendszert. Szerintem te a hajadat kitépnéd, hogy közel 10 alrendszer összedrótozásával készül el.

Ebben erősen tévedsz. A levelőrendszerünket én magam állítottam össze tokkal vonóval jónéhány évvel ezelőtt (kolléga is írt némi szkriptet, de végül én pofoztam véglegesre):

- 2db mx szerver (postfix), csak leveleket fogadni, spam szűrés, saját vírus karantén megoldás

- 1db mailbox szerver (dovecot), de lehetne több is (valószínűleg lesz), ezt el sem lehet érni kívülről

- 1db smtp szerver (postfix), ami kiküldi a leveleket, ez sem érhető el kívülről

- 2db proxy szerver (nginx), ami mailbox vagy smtp felé továbbítja a csatlakozást, akár több mailbox felé postafióktól függően, fiókonként lehet korlátozni, hogy pop3/imap/smtp legyen használható

- mx2 funkcionalitás, azaz ha máshol van az elsődleges smtp, oda továbbít, ha nem érhető el, parkolnak a levelek

- a fenti ldap alapon konfigurálható, mx2 esetén az érvényes címzettek importálhatók (érvénytelen címzettnek szóló levelet ne vegyen át)

Ezenkívül van keepalived keretrendszerem, kvázi tetszőleges szolgáltatást be lehet könnyen integrálni, biztosított a konfiguráció szinkron is.

És több egyéb.

Nyomod a dobozost.

Ha nincs normális nyílt forráskódú/ingyenes, akkor igen, a virtualizáció tipikusan ilyen terület, nem ismerek ütőképes megoldást. Tompos kolléga sem igazán volt meggyőző, hogy finoman fejezzem ki magamat ("feltételezem", "borg első pillantásra tudja, de dunno, nem használom a borgot", "Amúgy az az a szitu, windows guestek, amikor az esxi inkább preferált" - nem sok következő találkozó lenne, ha ilyeneket mondanék egy ügyfelemnek, mint megoldásszállító mérnök).

ESXi: szerver oldalon 2002-ben kezdtem FreeBSD Jaillel, majd Linux Vserver. Mikor kijött/ingyenes lett a VMware Server (Workstation egyszerűsített szerver oldali változata), akkor rájöttem, hogy ez sokkal jobb, nincsenek vele olyan szívások, mint az előző kettővel. 2007-ben döntöttem úgy, hogy kanyar ESX felé, de azt nem igazán lehet hobbi szinten űzni, így elhatároztam, hogy üzletszerűen fogok vele foglalkozni. Ehhez az elhatározáshoz annyit kell tudni, hogy mikor kijönni a VMware Workstation béta, nekem szerelem volt első látásra. Persze elhatározáson kívül elég sok munkát is bele kellett fektetni, mert nem volt hasonló téren tapasztalatom: labor építések, rengeteg olvasás, tanfolyam stb.

Ennek köszönhetően bepillantást nyertem a nagyvállalati informatikába, ahol sok mindent lehetett tanulni, például rendelkezésre állást illetően. Mindent nyilván nem lehet 1-2 szerveres környezetbe lecsorgatni (pl redundáns tároló, de erre is van kivétel), de az ESXi-t, mint hipervizort igen: minek kínlódjon az ember mással, ha normálisan működik OS-től függetlenül. Mentő szoftver is van hozzá, illetve akár egy Synology (nem mind) is tud VM-et menteni, csak a hardver árát kell kifizetni (de tény, hogy szintén zárt...).

Gondolom sokan azért nem mennek Linuxból ESXi irányba, merthogy zárt, emiatt elakadnak és észre sem veszik a megoldás nagyszerűségét, lehetőségeit. Az nyilván más kérdés, ha valaki hobbiból szeret babrálni és ideje végtelen, de ezek a jellegű problémák inkább szívás kategória számomra, mintsem kreatív tevékenység. Ha annyira drága/problémás lenne az ESXi, bőven lett volna idő valami Linux alapúval kiszorítani, de ez nem történt meg. Vannak cégek, ahol mással próbálkoznak, sok helyen szívesen megspórolnák a vSphere árát, de végül inkább kifizetik, illetve most már inkább a felhő az irány, nem valami Linux alapú.

Mentés kapcsán lehet szkriptekkel bohóckodni, de ha látsz egy normálisan működő Veeam rendszert, mindent kidobsz a kukába és újragondolod az addigiakat. (kivételes helyzetek, esetek nyilván mindig vannak)

De annak ellenére, hogy szeretem a Veeamet, nem dobozosan használom, mert tipikusan célszerű több feladatot létrehozni, amik nem mindegy, mikor futnak, illetve több feladat esetén több értesítést keletkezik, ezenkívül azért szükséges lehet némi integráció más folyamatokkal. Erre fejlesztettem egy szoftvert, ami külső parancsokat is futtat és elfogja a kimeneteket (pl. robocopy, ssh, truecrypt becsatolás, ...) és egy összesített jelentést küld, aminek a tárgyából az üzemeltető látja, hogy minden rendben van-e, ha nem, akkor a levélből az is kiderül, hogy mit kell keresnie.

Más hasonló fejlesztésem is van dobozos szoftverekre, amiket nem next-next-finish módon használok.

Azaz az, hogy dobozos a szoftver vagy sem, a legózás szempontjából baromira mindegy.

Amikor kollégát veszek fel, akkor így kezdődik a listám:

Igazán jó, hogy remek kollégáid vannak, csak ha például egy ilyen kollégádnak (akit becsülsz, értékelsz) kell merevlemezt cserélni, partíciós táblát kreálni, md-be felvenni leírás, távirányítás alapján és véletlenül elront valamit, aminek adatvesztés az eredménye, akkor vele csesztél ki (nem magaddal, hanem vele). És akkor még nem is alaplapot cserélt.

Páran azt gondoljátok, ahol egy balfaszság van, ott kell lennie többnek,

Mindenhol van balfaszság, hol több, hol kevesebb, hol kisebbek, hol nagyobbak. Ha jól gondolom a mérlegedet (048 a vége), összességében közel sem vagy balfasz (sőt, én akkor sokkal inkább), éppen ezért is érthetetlen számomra a pitiánerkedésed, mikor még arról sincs szó, hogy 0,2%-ről 0,3%-ra kellene növelni a költséget (ha a balfaszkodó idődet is számoljuk, akkor szerintem fordított a %-ok alakulása). Például a blogod alapján nyitott és érdeklődő is vagy, itt mégis mintha lenne egy rövidzár. Az persze más kérdés, ha szereted az expótér felé vezető utat, az adrenalint, a zúgást, a sztorizást, de ha például azt az időt a levelezés fejlesztésére fordított, akkor szintén van flow élményed, haladsz is és a céged sem áll meg.

Ha a gyerek elvágja magát a késsel, akkor nem ez a megoldás, hogy fakést adunk a kezébe, amivel csak reszelni tud, hanem tanítjuk. Kivéve, ha még csak 1 éves, mert akkor valóban várni kell. :-)

Istenem, kezdesz kiakasztó lenni. Mit akarsz. mérjük össze, kinek nagyobb?

Fogd fel. h a usernek más az igénye, mint neked. És ertsdy, h ezt nem vagy képes befogadni.

 

Kurva módon zavar most már az ellenséges, támadó, kihívó stílusod.

 

Van két rendszer, amik között vannak átfedések és nem univerzálisan mindenre jók. Finoman szólva, ha ezt nem tudod processzálni az emeleten, akkor engineernek és sales-esnek is olyan vagy, amilyet korábban én nem állítottam esdig sosem a topicban. Eddig.

 

Na csókolom, ne koptasd tovább a nevem.

Nyugodtan lenyugodhatnál, a téma ott kezdődött, hogy te vontad kétségbe az én állításomat (esxi), tudásomat megkérdőjelezted (értékesítő, nem értek a linuxhoz), kérdésre nem tudtál válaszolni, csak maszatolni (mentés), végül oda kanyarodtál vissza, amit én állítottam (esxi).

Bárhogy is nézem, ez komolytalan és nem értem, miért kellett volna mindezt jó néven vennem, számos alkalmad lett volna konstruktívan hozzászólni, de számodra az volt a fő szempont, hogy bebizonyítsd, nem értek hozzá.

Az utolsó beszólás tényleg lehet, hogy nem kellett volna, szori.

De a lényegi tartalmát fenntartom, miszerint továbbra sem látok ütőképes linux alapú virtualizációs megoldást. (talán nem túlságosan elvetemült dolog a Windows támogatást is beleérteni az elvárások közé, itt is felmerült)

További szakmai sikereket kívánok.

A mentéstől lenne ütőképes? 

Amit én tudok erről:

raid1 -> lvm -> wm

Nem wm-ről csinálsz mentést, hanem az lvm-ről. dd majd restart & sync  ez jár egy újraindításnyi időkieséssel (10-30 sec), de cserébe full backup.

Miért nem működik az értesítések tiltása?

A hozzáértésed garantáltan noncs meg. mivel még azt sem sikerült levenned, h mi a probléma. Csak ismételsz, mint egy papagáj.

 

BTW, alkalomadtán mérjük össze. Mmint azt, h kinek a megoldása jobb kompletten, TCO-val, fenntartással. Aztan kiderül.

 

Na remélem, most már tényleg sikerül tiltani ezt az ízét.

Neked ez balfaszság, másnak meg stáció. Nem veszed figyelembe, hogy amiket vettem még az is ágyúval verébre. Azon a szinten amin én vagyok (rendelkezésre állás szükségessége), a választásom az optimum és abból meg az ágyú, amit vettem.

Nekem teljesen oké, ha rsync ssh-n át tolja a telephelyre az adatot, ott meg rsnapshot elkészíti a backupot. Amit érdemes még megtennem az ERP adatbázisát szétkapni több db-re. pl tök feleslegesen van ugyanabban a db-ben a log. 

Írtam konkrétumokat, amiket nem fogadtál el.

Egyébként láthatóan azért, mert más a szempontrendszered (eg. "vendor lockin és hasonlók legfeljebb oss geek szinten érvek esxi esetén, nem üzletileg"). Ami tök jó, ha nem lenne az embereknek különböző ízlésük, akkor nem lenne ezer megoldás és nem fejlődne a világ.

 

Csak azért írom, mert nekem aztán tökmind1. Mivel továbbra is ellenséges vagy, a részemről lezárom.

Ebben nincs tapasztalatom.

Ez nem tapasztalat kérdése, nézd meg bármelyik nagy IT vendor (HP, Microsoft stb.) képzési útját. Először is a képzések két úton haladnak:

Kereskedelmi:

Sales -> Presales

Technikai:

Technician -> Engineer -> Master Engineer

A két út eleve különbözik, a Sales és Presales az aktuális termékvonalat, a termék pozicionálását, a felhasználási terület beazonosítását és az eladást támogató eszközöket ismerik.

A technikus és mérnök pedig a hardvert, annak telepítését, konfigurálását stb. Végzi.

Autós példa:

Sales, Presales = autószalonban az autót mutogatja.

Technikus = Autót szereli

Engineer = A tuningot reszeli

trey @ gépház

Sales, Presales = autószalonban az autót mutogatja.

Nem tudok értelmes autós analógiát hozni, de a kettő azért nem egy kategória. A presales vonalon dolgozó ismerőseim mögött általában 10-20 év mérnöki karrier áll. Mármint nyilván azoknak, amelyek relatíve sikeresek a szakmájukban, és az ügyfelek is szeretnek velük dolgozni. Igaz, ők arra is képekes, hogy néha széttárják a kezüket, és azt mondják, hogy az ő termékükkel ezt így nem lehet/ajánlott megcsinálni.

Igen, ez egy ilyen műfaj.

De pont ez a csapda benne: Oregonnak nem volt kellő tapasztalata, valamit kellő magabiztossággal adtak elő, kétely sem merült fel, benyelte.

Amellett, hogy ezt benyelte azt is hibázta, hogy 0,2%-ot költ IT-re, azaz a sóher ügyfél mintapéldája, csak tájékozottabb kivitelben. Ha többet költ, akkor lehet, hogy megfelelő szakember kezébe kerül a kérdés és nem történik ilyen probléma - bár tény, hogy akkor nem lehetne jót sztorizni rajta, egy unalmas rövidebb leállás lett volna. A parkettázónk ilyenre mondta: nem mindegy, hogy szakma vagy szakkör.

A hozzáállása alapján majd mással fog hasonlóan beszívni valamit vagy felnyomják az oldalát, mert 25 évig jó volt, akkor további 25 évig is az lesz, aztán majd megint megkérdezi, hogy ki a jó szakember, a biztosítás pedig hülyeség.

Egyébként élőben demózta le az áthelyezést, ugyanolyan vagy különböző szerverek (vezérlők) között?