2. Fórumok
  3. LOGOUT reakciók
  4. shadowkidhu: SFF Itthoni labor
Keresés

Új hozzászólás Aktív témák

  • #38 LZs?! aktív tag bambano #6
    Új Válasz #38
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    LZs?!

    aktív tag

    válasz bambano #6 üzenetére

    Fentebb mások már kifejtették a 'miért', illetve 'minek' kezdetű, virtualizációval kapcsolatos kérdésekre a válaszokat, és a praktikus szempontok bő javával mélységesen egyet is értek. A l'art pour l'art jellegű next-best-thing-ever motívumok pedig nem mozgatnak a kitárgyalt szempontok közül; se pro, se kontra.

    Egy gondolatodra reagálnék:

    Szerintem vm-et marokszám az üzemeltessen, aki meg akarja tanulni a vm-eket, hogy esetleg később fizetős melóban használja.

    Ez! Ez itt a lényeg.

    Nagyvállalati téren abszolút, de már KKV szinten is a virtualizáción alapul az operatív infrastruktúra zöme; egy gigantikusan túltolt SAP ERP-tól kezdve, Béla 'urna-és-virág-webshop' webelérésű menedzsment applikációjával bezárólag. Legyen az 'generic-big-cloud' (GCP/AWS/Azure), 'solution-specific-cloud' (pl. SAP S/4HANA, Anaplan Cloudworks, Salesforce, etc.) vagy on-premise vason futtatott virtualizáció lokálisan, illetve akár netre engedve.

    Nagyobb jövőkép van a virtualizáció összefüggéseinek, protokolljainak, konfigurálásának, etc....de főleg a praktikus alkalmazhatóság elveinek legalább alapvető elsajátításában, mint a 'hagyományos' (legacy?) IT alapokban...főleg, hogy akár az előző bekezdésemben említett példákban is a nap végén a dedikált 'techy' weblinken elérhető különböző webfelületeken fogja őket használni kvázi alkalmazásként, akár frontend-et, akár backend-et abúzál éppen.

    ...és ebben a környezetben konkrét példa VM-re: GCP data store ETL output-ját a Salesforce irányába egy felhőben hostolt Linux VM pakolgatja scriptelt schedule szerint a vonatkozó felhők ködök egress és ingress API-jai között a 'semleges űrben', ahol csak ő létezik és a két API connection-je, elzárva mindentől. Ez az egy dolga van. Kvázi microprocess. Miért? Mert így mindenkinek igaza lett a végén. #solutiondesign

  • #4 LZs?! aktív tag bambano #1
    Új Válasz #4
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    LZs?!

    aktív tag

    válasz bambano #1 üzenetére

    A RAM kérdésben csatlakoznék a kollégához: parancssoros Linux VM kifuthat 2GB/VM körül (kalandvágyóknak: 1GB + barebone funkcionalitás; tesztelni elég pl. connectivity, etc.), de GUI-s Linux is megkéri a legalább 4GB memóriát és 2 magot, hogy érdemben reszponzív legyen. A CPU időt a hypervisor tudja ütemezni, így tehetsz 20 VM-et is akár a 8 magra, legfeljebb esnek-kelnek egymáson, és nem fognak kapkodni közben; ellenben még ha dinamikusra is állítod a mermória menedzsmentet (pl. range: min 2GB, max 4GB), amit a VM egyszer már allokált magának a 'burkában', azt a hypervisor már nem tudja (fogja) elvenni.

    Ugyanakkor abban nem értek egyet, hogy nem érdemes VM-be csomagolni: szerintem mindent, ami egy szolgáltatás csomagként operál, érdemes egy-egy különálló VM-be tenni: kompartmentalizáció. Utána mind a change/modify/replace, mind a backup/restore is könnyebb, példa okáért: OPNsense 'routert' (sic!) futtatsz és valami megcsúszik benne - akarsz hibát keresni? Igen -> go for it. Nem -> importálsz/onboard-olsz egy exportált 1:1 (biztonsági) másolatát annak a VM-nek és mész tovább. ...és nagyban is igaz ez a VM-ek összességére, ha megcsuklik a kemény vas az egész hóbelevanc alatt.

Új hozzászólás Aktív témák