- Yettel topik
- Honor Magic5 Pro - kamerák bűvöletében
- Ezek a OnePlus 12 és 12R európai árai
- Android alkalmazások - szoftver kibeszélő topik
- A Watch7-tel debütálhat a Samsung vércukormérője
- Garmin Forerunner 255 Music - nem csak futóknak
- Megérkezett a Google Pixel 7 és 7 Pro
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Honor 50 - apám nevében
- Olcsó 5G-s ajánlatot nyújt a Realme Indiának
Hirdetés
-
A Video AI lehet a One UI 6.1.1 ütőkártyája
ma Vagy hogy fogja a mesterséges intelligencia manipulálni a mozgóképeket?
-
Konzolokra is megjelenik a Deathbound
gp A PC-s verzió mellett megkapjuk a teljes kiadást PlayStation és Xbox platformokra is.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Mobilarena
--- Még az új vizsgarendszer előtti információk, majd frissítjük! ---
Gyakran ismételt kérdések
Olvasd el a cikkeket itt.
Új hozzászólás Aktív témák
-
vadger
tag
válasz stfreddy #15699 üzenetére
Eddig két multi cégnél kerültem kapcsolatba cloud-dal, és ugyan nem vágom pontosan mibe kerül, de sehol nem problémáztak néhány ExpressRoute vagy Hybrid Connectivity kapcsolaton. Cloud-ba VPN interneten az max ilyen végszükség esetén kategória volt.
De itthon valószínűleg nem sok cég vállalja be ezt a plusz költséget.CCNA RS, Security és egyéb hálózati témák oktatása: https://ccnaoktatasmagyarul.hu
-
olloczky
senior tag
válasz Ripper17 #15687 üzenetére
Jo kis beszélgetés folyik itt.
Pont a napokban hagyta el a szamat nekem is ez a felvetes, hogy kb 90-95% meg mindig legacy networking. En igy hivom a nem cloud dolgokat.
Szoval en most fogok valtani sdwanrol vissza az emterprise, legacy, rs (hivjuk barminek) networkingre es orulok, hogy ugy latjatok, hogy menni fog meg ez egy darabig, akkor talan nem dontottem rosszul. Meg ha megis sdwanra akarnak menni, akkor van tapasztalat :)
Úgy még sosem volt, hogy valahogy ne lett volna!
-
soma314
tag
Nem akarom a vitát szítani, mert szerintem sokan akik idetévednek egyrészt nem ezt akarják olvasni, másrészt félő, hogy valaki végképp félre érti.
Ami lényeg: a felhő van, nagyon sok esetben az a jobb megoldás és a jövőben terjedni fog.Ugyanakkor az on premise DC mellé még egy nyomós műszaki érv: a helyi server farmot a lan oldalról sokszorta nagyobb sávszélességgel és saját QoS szabályokkal éred el és már alaposan kibeszéltük sokszorta alacsonyabb latency-vel éred el, mint az interneten keresztül egy távoli server farm-ot (felhőt).
Ne keverjünk fogalmakat kérem: az SD-WAN és úgy általában az SDN és a Cloud Computing két külön fogalomkör. Az egyik nem feltétele a másiknak. Az a közös bennük, hogy mindkettő az elmúlt években divatossá vált buzzword-ök. Na és mind a kettő létezett régen is, legfeljebb nem így hívták. Legalább a szakmában ne dőljünk be 1:1-ben a marketing szövegeknek!
-
crok
Topikgazda
válasz soma314 #15706 üzenetére
+1 én se tudnám PC-bb módon leírni ugyanezt. Lesz amire ez lesz jó, lesz amire nem lesz jó.
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
suomalainen
tag
válasz soma314 #15698 üzenetére
"Ehhez nincs köze a DMVPN-nek, legfeljebb anyiban, hogy DMVPN-t jellemzően hagyományos internetkapcsolaton építenek ki. De ezt nem kell feltétlenül így csinálni, lehet akár "bérelt vonalon" keresztül is."
Ez ugyanúgy igaz a cloud elérés esetében is. Becsattanhatsz bérelt vonalon is saját tűzfallal. Igy a latency probléma a cloud esetében meg is oldódott.
""Building the Cisco Cloud with Application Centric Infrastructure" Hát ebben a mondatban sem nevezi az ACI-t felhőnek, hanem egy eszköznek, amit felhőszolgáltatásokhoz létrehozásához ajánl."
Arra céloztam, hogy én azt állítottam, hogy az ACI régen a cloud irány része volt. Se többet, se kevesebbet.
"Miért lenne corner case szituáció? Mert rámutat a felhős megoldás hiányaira? [...] Ez azt jelenti, hogy feleslegesen küldjül el a packetek nagy részét az internetre és vissza.
Ez igy is van, de a gyakorlatban mégis a neten keresztül csattanunk fel egy szerverre."Mer' az csak úgy megy, hogy a szolgáltatásodat átviszed egyik kontinensről a másikra! És átküldöd a ki tudja mekkora adatmennyiségedet e-mail csatolmányként?"
A cloud nem úgy épül fel, hogy van egy ajtaja valahol a világban, bemész rajta meg kijössz. Az Azurenak pl rengeteg DC-je van és simán megoldható, hogy egy szolgáltatást Nyugat-Európába telepíted, de keleten van a redundáns DC-ben a backup.
"Persze, hogy megtörténhet privát DC-vel is, de egy privát DC-t te felügyelsz, te tudod milyen óvintézkedések vannak, hogy ne történjen meg. Ha meg havária van, akkor a privát DC minden embere a te DC-d helyreállításán dolgozik, míg amikor egy felhőszolgáltató döl be, akkor az 1024-dik leszel, akit helyreállítanak."
Ez nem úgy működik, hogy "feltörték a cloudot" és szaladgál mindenki, mint pók a falon. Hogy a te dolgaid biztonságban legyenek te felelsz, amire rengeteg megoldás létezik. Attól még a másik customer lehet hanyag és feltörhetik a hálózatát, de ez téged semmiben nem fog érinteni.
-
soma314
tag
válasz suomalainen #15708 üzenetére
"Ez ugyanúgy igaz a cloud elérés esetében is. Becsattanhatsz bérelt vonalon is saját tűzfallal. Igy a latency probléma a cloud esetében meg is oldódott."
Ez sajnos nem így van. A DMVPN, vagy "bérelt vonal" vagy akármi, ami a te saját telephelyeidet köti össze, azok általában nem olyan nagy földrajzi távolságok, leginkább néhány 100 km. Egy felhőszolgáltatás meg akár lehet egy másik kontinensen.
Amíg magadnak rendelsz "bérelt vonalat" két vagy több telephely között, addig általában egy szolgáltatón megy keresztül egy-egy vonal. Hány szolgáltatóval kell szerződnöd egy másik kontinensen lévő felhőszolgáltatás elérésére. No meg hogyan máred, hogy betartják-e az SLA-kat? Az rendben, hogy látod, hogy a végeredmény nem fogja kiadni a szerződések együttes tartalmát, de mégis melyik szolgáltatónál reklamálj?
Arról nem is beszélve, hogy a "csőnek" az egyik vége lesz csak nálad, ha "becsattansz egy bérelsz vonallal a felhőszolgáltatóhoz. Ez popszakma meg olyan, hogy attól, hogy odafele jó a latency, jitter, svászélesség, attól még visszafele simán lehet rossz.
Technikai kérdés, de csak gondolj bele egy szolgáltató saját hálózatán át tudja vinni CE-től CE-ig mpls-en integrated service QoS-el a packet-jeidet, míg, ha szolgáltatókat váltasz, annyiszor lesz egy-egy PE-CE-PE (provider-edge, customer edge) .
A másik lényegi dolog, hogy ha a P2P vagy P2MP tunnel, amit te kértél egy szolgáltatótól az a te DC-den az általad ismert sávszélességgel csatlakozik az internetre és te állítod be ki, mely tunnel-ek tudják azokat használni és milyen esetleges QoS policy-val kit milyen mértékben korlátozol. Ezzel szemben egy felhőszolgáltató internetkapcsolatára nincs ráhatásod. Nyilvánvalóan piszkos anyagi okból oversubscibing van ott is. Egy tranziens terhelés esetén elég jó eséllyel megsínyli valakinek a szolgáltatása."Arra céloztam, hogy én azt állítottam, hogy az ACI régen a cloud irány része volt. Se többet, se kevesebbet."
Egészen pontosan ezt írtad:
" Amit a Cisco cloudnak nevezett, az gyakorlatilag az ACI volt (ma a DC irány része)."
Egyébként szerintem az ACI a DC vonal része volt és annak a része ma is."Ez igy is van, de a gyakorlatban mégis a neten keresztül csattanunk fel egy szerverre."
Már aki és már amihez. Nem csak SOHO-ból áll a világ. Léteznek komoly üzleti, ipari, katonai hálózatok is."A cloud nem úgy épül fel, hogy van egy ajtaja valahol a világban, bemész rajta meg kijössz. Az Azurenak pl rengeteg DC-je van és simán megoldható, hogy egy szolgáltatást Nyugat-Európába telepíted, de keleten van a redundáns DC-ben a backup."
És hogy megy át? És, ha vavária volt, és teszem azt a semmiből kell felépítened egy harmadik szolgáltatónál, mert az Azure-ban már nem bízol, akkor hogy kapod meg? Küldenek egy fél teherautónyí HDD-t, amit aztán upload-olsz?
Az egész felhő, de akár a hybrid technológia egyik Achiles sarka, hogy az igazán fontos dolgokhoz neked egy adatbázisra van szükséged minimum két példányban. (Ez nem a backup mielőtt ebbe valaki beleköt!) Ha az egyik kiesik, a másikról hitless menjen minden tovább. A baj ott kezdődik, hogy ehhez nagy sávszélesség és kis latency kell. Meg lehet csinálni mindezt Azurban úgy, hogy van egy ilyan "kettőzött" storage-on Berlinben, meg Hongkong-ban is, de azt nem lehet, hogy Berlin és Hongkong között legyen megosztva a storage kettőzése. Ennek az lesz a hatása, hogy amíg te azt hiszed, hogy ugyanaz van Berlinben és Hongkongban, addig a két helyszín időről időre szinkronizálja egymást. Tehát a két adatbázis a két helyszínen soha nem lesz azonos!
Ehhez jön a backup kérdés. Ugya azért van redundancia, hogy a folyamatos üzemet fenntartsuk. A backup másra szolgál. A példánál maradva: Berlinben egy ransomware tönkre teszi az adatbázist és mire észreveszed, addigra Hongkongba is átjutott a szinkronizálással a vírus. Na ilyenkor kellene elővenni azt a backup-ot, ami még garantáltan nem vírusos. Update-elni az IPS-t az őj víris szignatúrájával, majd a semmiről újradeployolni mindent a backup használatával. Ezt egy DC-ban meg lehet tenni. A felhőben is, csak ott kell lennie helyben hozzá a know-how-unak (a te szolgáltatásodhoz!) a backupnak...Na és valószínű ha egy új 0day sérülés érintett, akkor nem te voltál az egyetlen, aki így járt, ezért írtam, hogy te leszel az 1024-dik, akit helyreállítanak."Ez nem úgy működik, hogy "feltörték a cloudot" és szaladgál mindenki, mint pók a falon. Hogy a te dolgaid biztonságban legyenek te felelsz, amire rengeteg megoldás létezik. Attól még a másik customer lehet hanyag és feltörhetik a hálózatát, de ez téged semmiben nem fog érinteni."
Jaj, de most komolyan virtualizáció alapfokon: vannak vasak, amin futnak a hypervisor rendszerek (pl VMware, Proxmox, Hyper-V, Zen...). A Felhő azért éri meg, megy a vasakon, nem csak egy-egy cég VM-jai futnak, hanem folyamatosan több cégé. Sőt általában még azt sem lehet mindig előre tudni, hogy X cégé mindig csak Y, vagy Z gép virtuális gépeivel osztozkodik az adott vason, mert a VM-ek terheléstől függően a hypervisor clusterben szépen mászkálnak. Amikor egy VM-et "feltörnek", akkor azt azért is tehetik, hogy egy másik VM-hez férjenek hozzá a hypervisor-on futó virtuális hálózaton keresztül, de akár azért is, hogy a guest VM-en keresztül érjék el a host-ot, vagyik a hypervisor-t futtató vasat magát.
Persze van elvileg minden: mikroszegmentáció, meg a vas erőforrásainak korlátozása..., de mégis van minderre mód és történnek "feltörések". Ha az ember már nem kamasz, akkor ezt nem úgy képzeli el, mint a tévében, ahol a hacker egy szobából because he can alapon érzékeny adatokat lopkod, vagy éppen tölt fel, hanem esetleg már látott olyat, amikor bot-ok 10 ezreiről indítanak DDoS támadást, amitől a VM-ek memóriája, a prociterhelése túlnő azon amit a vas bír. Mert igen itt is van oversubscription: attól, hogy eladnak egy serverre 10x64 Giga RAM-nyi VM-et, attól még nem a serverben 640 Giga RAM, csak lehet 320. És akkor még nem beszéltem a containerizációról, ahol ez még akár sokkal rosszabb lehet. Hát hogy az mennyire felhő (IaaS) vagy inkább SaaS azt már nem is tudom pontosan eldönteni így hirtelen.
És igen te leszel a saját adataidért felelős, de nem lesz backup-od, nem lesz személyzeted hiszen elküldted az felhős outsource-ing miatt.
Engem nem zavar ez a tendencia, mert munkám lesz legrosszabb esetben felhő szolgáltatóknál, sokkal valószínűbb, hogy a felhő szolgáltatásban már csalódott cégeknél. A tendencia és a "felhő" ismeret nélküli imádata pont azokra a kollégákra "veszélyes" akik most SOHO szektorban dolgoznak. Elnézést, de egy batanított majom is tud egy Meraki-t beüzemelni egy fagyizóba, de egy DC-hez, nagyvállalati környezethez, felhőszolgáltatáshoz már kecskepásztor kell. -
kenwood
veterán
válasz soma314 #15709 üzenetére
"Egy felhőszolgáltatás meg akár lehet egy másik kontinensen."
Persze, csak arra nem fog senki elofizetni.
Kiveve, ha a latency nem szamit, a bandwith pedig megvan.Ez csak az Azure, az AWS es a Google is legalabb ekkora.
[ Szerkesztve ]
Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben
-
soma314
tag
válasz kenwood #15710 üzenetére
Az a baj, hogy ez már megint inkább dezinformáció, mint információ. A térképen ugyanis Európa azért "zsúfolt", mert a terveket / vágyakat is tartalmazza. Ezzel szemben a rideg valóság. Európában elérhető, meglévő Azure központok: Írország, Hollandia, Norvégia, Németország, Anglia, Franciaország, Svájc
https://azure.microsoft.com/hu-hu/global-infrastructure/geographies/Az AWS: Írország, Anglia, Svédország, Franciaország, Németország, Olaszország
https://aws.amazon.com/about-aws/global-infrastructure/Google: Anglia, Belgium, Hollandia, Németország, Svájc, Finnország
https://cloud.google.com/about/locationsmindegyiknél a legközelebbi talán Németország ide, és mi még "szerencsések" vagyunk.
És ezen elérhető helyszínek jelentős része nem üzemel 2 éve. Tehát biztosan "jól ki van próbálva" és érdemes beleugrani béta tesztelőnek![ Szerkesztve ]
-
kenwood
veterán
válasz soma314 #15711 üzenetére
Az ok, en csak arra reflektaltam, hogy akar masik kontinensen is lehet a server.
Az mondjuk tisztan latszik a terkepeken, hogy nekunk egy orosz cloud provider lenne a legjobb opcioMi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben
-
suomalainen
tag
válasz soma314 #15711 üzenetére
Értem már mi a problémátok. Nektek Magyarország a világ közepe és ehhez mérten viszonyultok a cloudhoz. Hány olyan MO, vagy Kelet-Európai cég van, ami elmondhatja magáról hogy multi?
Mit jelent az, hogy "jól ki van próbálva"? Mit gondolsz, mi ez valami autó, amit be kell járatni? A cloud egy licensz, ami ha működik, akkor működik bárhol. De ha már itt tartunk, felmerül bennem a kérdés, hogy a -clouddal szemben- az on.-prem DC, amit összedobtok, azt mennyire kell tesztelni? Nincsenek illuzióim ezzel kapcsolatban.Amiből kiindult ez az egész beszélgetés az az, hogy azt állítottam, hogy az Enterprise vonal halott. Minél többet beszélünk róla, annál inkább megerősödik bennem ez a gondolat. Egy Catalyst switchcsel te nem csinálsz on-prem DC-t, ahhoz DC tudás kell.
Még egy dolog: a cloudot ne csak a network oldaláról közelítsétek meg, hanem szerver oldalról is. Egy on-prem DCben elég komoly lehet a kapacitás kihasználatlanság, ami a cloudról nem mondható el.
[ Szerkesztve ]
-
soma314
tag
válasz suomalainen #15713 üzenetére
"Hány olyan MO, vagy Kelet-Európai cég van, ami elmondhatja magáról hogy multi?"
magyar: OTP, MOL hogy legismertebbeket mondjam, de mi köze ennek a claud-hoz?
Azt jelenti, hogy ismert technológiákat használsz, amihez van tapasztalat. A felhőtechnológiákhoz még nincs sok.
Elég rendesen kell tesztelni.Sőt tudok olyat is, hogy van egy "legacy" DC éles üzemben és évek óta üzemel mellette tesztben egy újabb. Csak akkor fognak átállni rá, ha megyőződtek róla, hogy kellően megbízható és érdemes migrálni. Mindegyik on premise.
Az a baj, hogy én meg pont úgy látom, hogy illuzióid vannak inkább csak.
Miattam hiheted azt, hogy az Enterprise vonal halott. Ha valakit erről meg tudsz győzni, annak úgy kell. Nekem nem fáj, kisebb lesz a konkurencia
Senki nem mondta, hogy Catalyst-tal csinálnak DC-t, bár akár. Sok sok olyan rendszert láttam, ahol Nexus switch-ekkel oldottak meg Catalyst-eknek való feladatot, mert az volt olcsóbb, azt ismerte a tervezője jobban...
Óriási különbség nincs funkciókat tekintve és az ISO-XE és az NX-OS működésében sem. Mindegyikél van MLAG, mindegyikkel meg lehet valósítani L3-as technológiákat. Midegyikből van szekrény méretű és 1 U-s is...
Ami lényegi különbség, az az FCoE (Fiberchannel over Ethernet) ha egyben akarod megvalósítani a SAN és a LAN switch feladatokat, akkor Nexus kell. Ha a klasszikus modelt követed és külön SAN hálózatot építesz ki, akkor MDS (ha már Cisco) és hagyományos FC, ha meg "trendi agy", akkor hyperkonvergens szervereket használsz és nincs is fizikai SAN hálózatod. Na és persze nem csak a Cisco-ban lehet és kell gondolkodni. Ott van például az Arista, ami DC környezetben eléggé jó piaci részesedésű. Azt udtad, hogy az Arista alapítója tervezte a Catalyst 6500-ast? És tudtad, hogy az EoS (Arista oprendszere) kísértetiesen hasonlít az ios-re? Én például megtaláltam benne ugyanazt a bug-ot No meg, hogy peren kívüli egyezséggel kötöttek békét a Cisco-val?
Ennyit arról mennyire van távol a Catalst világa a DC-től.
"Egy on-prem DCben elég komoly lehet a kapacitás kihasználatlanság, ami a cloudról nem mondható el." Ez blődség egy DC-ben függetlenül attól, hogy on premise, vagy cloud a kihasználtság attól függ milyen és mennyi task-ot, VM-t, container-t...futtatsz rajta.
Ha már építettél DC-t, vagy foglalkoztál kicsit mélyebben a kérdéssel, akkor tudod, hogy egy C környezetben a skálázhatóság korlátja, nem a szerverek száma, a memória, a storage kapacitás... hanem leginkább a hely és utána rögtön a hálózati átviteli képessége. A hagyományos hardverek (CPU, RAM...) sebessége, mérete évről évre jelentősen nő ahhoz képest, hogy a hálózatok átviteli képessége hogy alakul, különös tekintettel az internetre.
Kicserélni az összes szervert egy olyanra, ami 20%-al gyorsabb, vagy több memória bankolható bele simán megérheti, ha azt nézed, hogy mennyibe kerül egy DC kibővítése (építészetileg, tápellátásilag, klimatizálással, kezelt levegővel...). Ez a fizkai bővítés ráadásul a "zöldmezős" beruházásoknál lehet pálya, mert egy város központban lévő DC bővítéséhez nem tudod lebontani a szomszéd háztömböt. A Microsoft például ezért (is) kísérletez tengerbe merített DC-kkel.
Viszont én úgy látom, hogy nálad sem a szakmailag kiveséztük a témát a többi dologra meg annyit tudok mondani, hogy "a kutya ugat a karaván halad". -
FecoGee
Topikgazda
Sziasztok!
Úgy látom picit kezd személyeskedésbe menni a téma, kérlek titeket erre figyeljünk oda. Nem kell, hogy egyezzen a vélemény, de annyit nem ér az egész hogy feszültség legyen köztünk!
Azzal én sem értek egyet hogy az Enterprise Networking halott lenne. Gondolj csak a DNA-ra, nyomják ezerrel, fejlesztik. Az én tapasztalatom alapján és az ügyfelek ahol dolgoztam mindenhol messze álltunk az SDN alapú működéstől. Jobb esetben volt rá teszt, meg tervek, de legtöbb helyen bizony a jó öreg OSPF/BGP dolgozott. Sok helyen baromi régi Catalyst-ok üzemelnek, fényévekre van az SDN, és nem is feltétlenül kell a skálán egyből a legmagasabbra ugrani.
A DC-s részről nem nyilatkoznék mert nekem peremterület és nem látok bele részletesen, de mindenki mondandójában van szerintem igazság. Abban is, hogy ne Magyarországból induljunk ki feltétlenül, de én mondjuk csak abból tudok, hiszen nekik dolgozom. Amit látok a cégnél hogy megy az ACI és a sima VXLAN alapú fabric is, méret kérdése.
Én pl. most tesztelek SD-WAN-t és SD-Access-t is, mindkettő enterprise irány. Meg kell hagyni baromi drága. Az SD-WAN-nál a licenszek, az SD-Access-nél a DNA Center plusz a licenszek. Nem könnyű rá forrást szerezni. Viszont pont most tesztelünk Cisco 1800S szenzorokat a DNA-vel, egyelőre nem jött össze a dolog mert a 3rd party SSID csak 2.1-től támogatott mi meg 1.3-n vagyunk, de pl. ez is tök jó kis eszköznek tűnik.
Illetve én még mindig hiszek abban, hogy az R&S (már csak azért is így hívom) mindennek az alapja, utána lehet menni más irányba. Elfogadom, hogy jönnek az SDN dolgok és hogy tényleg ki kell tekinteni a határon túlra, de én megmondom őszintén hogy nem érzem magam "elavultnak" a magam kis RS tudásával, egyelőre (és szerintem még jó ideig) van bőven olyan projekt ami ide kapcsolódik, az újakat pedig tanulom hozzá.
[ Szerkesztve ]
-
suomalainen
tag
válasz soma314 #15715 üzenetére
"OTP, MOL hogy legismertebbeket mondjam, de mi köze ennek a claud-hoz?"
Nekem is eszembe jutott ez a két cég, de valljuk be, nem ezek szolgáltatják a világ GDPjének jelentős hányadát. Én multicégekről beszéltem a kezdetektől fogva."Azt jelenti, hogy ismert technológiákat használsz, amihez van tapasztalat. A felhőtechnológiákhoz még nincs sok."
Hála istennek vannak olyanok, akik látnak fantáziát a cloudban és képzik magukat ebbe az irányba is."Elég rendesen kell tesztelni.Sőt tudok olyat is, hogy van egy "legacy" DC éles üzemben és évek óta üzemel mellette tesztben egy újabb. Csak akkor fognak átállni rá, ha megyőződtek róla, hogy kellően megbízható és érdemes migrálni. Mindegyik on premise."
Ezt én soha nem is vitattam, ezért beszéltem hybrid megoldásról. De nem magát a cloud által nyújtott szolgáltatásokat, hanem a customer-specifikus szolgáltatások cloud környezetben történő működését kell tesztelni."Senki nem mondta, hogy Catalyst-tal csinálnak DC-t, bár akár. Sok sok olyan rendszert láttam, ahol Nexus switch-ekkel oldottak meg Catalyst-eknek való feladatot, mert az volt olcsóbb, azt ismerte a tervezője jobban..."
Most meg ellentmondasz saját magadnak. Pont ezt mondtam én is, hogy egy mai modern DC-ben már csak nexust építenek be, nem hiszem, hogy bármilyen Catalystnek lenne keresnivalója ezen a téren."Ennyit arról mennyire van távol a Catalst világa a DC-től."
Ha neked sikerül egy ACI-t összehozni Catalysttel vagy egy Fabricpath-t vagy netán egy sima vpc-t én nagyon fogok neki örülni. De lehet, hogy nekem hiányosak az ismereteim."Ez blődség egy DC-ben függetlenül attól, hogy on premise, vagy cloud a kihasználtság attól függ milyen és mennyi task-ot, VM-t, container-t...futtatsz rajta. "
Utána meg elkezdesz érvelni pont az ellenkezőjéről. Én arról beszéltem, hogy parlagon heverő erőforrások lehetnek egy DC-ben, mind storage mind szerver oldalon. Fogyasztják az áramot ezerrel, foglalják a helyet stb."Viszont én úgy látom, hogy nálad sem a szakmailag kiveséztük a témát a többi dologra meg annyit tudok mondani, hogy "a kutya ugat a karaván halad"."
Az a gond az érveléseddel, hogy összemosol dolgokat, amiket én szét akarok választani. Az Enterprise nem DC, egy mai DC nem Catalyist, a mai network pedig nemcsak Ciscoból áll.
Oké a karaván halad, de merre? Az rendben van, hogy te úgy gondolod, hogy a karavánod jó irányban halad, én viszont azt vetettem fel, hogy nem biztos, hogy (csak) ez lesz a jövőbeli út. De ez is csak felvetés volt a részemről, te meg úgy kezeled a cloud technológiákat, hogy mintha az valami parasztvakítás lenne. -
kenwood
veterán
válasz FecoGee #15716 üzenetére
Jah atment erosen bunkoba a gyerek, de altalaban erdekes dolgokat szokott irni, igy elnezem neki. Nem is ertem, hogyha azt erzed, hogy igazad van,miert nem bizod a tenyekre a piszkos melot, minek lemenni a szemelyeskedes szintjere. Lehet, hogy lecsuszott par pohat a comment elott.
[ Szerkesztve ]
Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben
-
rihovszky
lelkes újonc
Ha a vizsgát nem tervezem megcsinálni, akkor rossz ötlet a kb. 4 éves CCNP Routeot (aztán Switch, meg nemtom mik vannak még) tanulni az új Enterprise Encor helyett, vagy nagyon elavult a régi? Meglett az első munkahelyem, kaptam hozzáférést egy oldalhoz, de csak a régi CCNP-k vannak fent videós formában, az újból meg csak a cert guide.
-
Ripper17
tag
De, az.
A klasszikus R&S témakörök szerintem nem sokat változtak, én most pont az ENCOR-ra tanulok a cert guideból és nincs sok meglepetés ezen a téren. Ugyanez a korábbi CCNA-n is, arra is simán fel tudtam készülni az eggyel korábbi cert guideból. Anno azt összenéztem, +/- 5% volt a fejezetek közti különség, a maradék szinte 1:1 ugyanaz volt, csak más sorrendben. A Cisco évek óta hivatkozik arra, hogy átállnak teljesen e-learningre, de elég sok szakemberüknek/szerzőjüknek jó biznisz az offline világ és hogy 3-4 évente szinte ugyanazt kiadhatják újra. Persze ez nem Cisco specifikus, más szakmai műveknél is ez van.
@rihovszky: érdemes összenézni a témaköröket (tartalomjegyzék) a régi és az új cert guideoknál. Cisco Press oldalon ezeket tuti eléred. Kétlem, hogy sok különbség lenne a lefedett témakörökben.
Más kérdés érdemes-e ezzel szisztematikusan foglalkozni, ha amúgy vizsgázni nem akarsz - ezzel kb. a beleölt munkaóráid piaci értékét részben ki is dobod... -
Yeffy
veterán
válasz Ripper17 #15721 üzenetére
koszi.
mar csak azert emlitettem meg, mert a kollega felettem ugy jellemezte, h csak a cert guide.egybk jo is, h emlited, akartam kerdezni, h en most fogok nemsokara nekikezdeni az ENCOR-nak meg az ENARSI-nak, es hogy van-e valakinek osszehasonlitasi alapja az elozo "rendszerrel", h kb mire szamitson az ember.
Big girls ride harder. ヅ || Kondi powaa'!
-
Ripper17
tag
Linkedin csoportokban lattam mar 1-2 kulfoldi vizsgazot ENCORbol, ok foleg lejart CCNP R&S-esek. leginkabb ugy latom a DevNet irany szolt most nagyot. Kivancsi lennek melyik vizsgak most a legnepszerubbek.
szerintem itthon kb mindenki az elozo rendszerbol athozasra gyurt ra, en is WIDESIGN+WITSHOOT december+februarban. aztan COVID, online vizsgat meg a ceg nem tudja téríteni. korabbrol amugy is valtas utan voltam CCNAbol es hat volt par "mire gondolt a kolto?" tipusu, nem tul kiforrott kerdes.
-
Yeffy
veterán
válasz Ripper17 #15723 üzenetére
ertheto. na majd szetnezek neten/linkedinen, mit irnak.
elore tartok a DevNet-tol, en meg a programozas...van mar egyebkent, vagy csak ugy altalanossagban jo/bevalt/ajanlott lab feladatcsomag a P szinthez? hasznal(t) itt valaki a topikban ilyet? ingyenes, fizetos (ha nem tul draga ), mindegy.
Big girls ride harder. ヅ || Kondi powaa'!
-
vadger
tag
válasz rihovszky #15725 üzenetére
Én azt mondom a DevNet jó irány a nyitottabb hálózatosok számára is. Számos hálózati feladat automatizálható, egyszerűsíthető ezáltal. Elég messze áll tőlem a programozás, de a tananyag nagy része azért érthető, gyakorlás mindenképpen szükséges, tehát nem csak elméleti vizsga.
CCNA RS, Security és egyéb hálózati témák oktatása: https://ccnaoktatasmagyarul.hu
-
kenwood
veterán
válasz vadger #15726 üzenetére
Nekem ugy tunik , hogy a Devnet egyelore inkabb a tudas bovitesere jo (foleg magyarorszagon).
Mig az enterprise,security,sp vonal onamagaban egy szakma,amibol megelsz, addig egy Devnet vizsgaval,vagy a mogotte levo tudassal nagyon kicsi az eselye, hogy itthon munkat talalsz.Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben
-
vadger
tag
válasz kenwood #15727 üzenetére
Igen, nem voltam egyértelmű, de én is úgy gondolom, hogy a meglévő hálózati tudás elengedhetetlen, és max utána jöhet a devnet vonal. Cisco lehet nem így gondolja, mert ők sima developereket is szeretnének látni devnet vonalon.
Igen, itthon nem tudom elképzelni azt, hogy valaki kijön a fősuliról, lerak egy devnetet és utána kapkodnak érte. De ha van már pár év tapasztalat, plusz ez, az azért nem egy rossz kombó.
Hogy csak egy példát hozzak ilyesmi állásra, legalábbis szerintem: [link]CCNA RS, Security és egyéb hálózati témák oktatása: https://ccnaoktatasmagyarul.hu
-
Yeffy
veterán
válasz rihovszky #15725 üzenetére
en mar csak ilyen konzervativ faszi vagyok, hasonloan gondolom, osztom vadger velemenyet is:
úgy gondolom, hogy a meglévő hálózati tudás elengedhetetlen, és max utána jöhet a devnet vonal.eloszor az alapokat akarom minel jobban elsajatitani, es lehetoleg gyakorolni, aztan "raerek" nezelodni mas fele. otleteim persze vannak.
valaki a fentebbi lab-os kerdesemre esetleg?
Big girls ride harder. ヅ || Kondi powaa'!
-
Ripper17
tag
válasz rihovszky #15725 üzenetére
vadger-el én is egyetértek, de azért idén télen Barcelonában látszott a Live-on: nagyon nyomja a Cisco a szoftveres vonalat. Több, új platform előadásán is elhangzott: már előbb írják meg az API dokumentációt hozzá, mint hogy a szoftver vagy a CLI guide kész legyen.
Nyilván ez a típusú megközelítés is az SDN irányába mutat, de magának a programozásnak más esetekben is van haszna. A Python nem egy nehéz nyelv, én utoljára egyetemen programoztam, de 1 nap alatt összedobtam most egy scriptet, ami tetszőleges sablonból és egy tetszőleges .csv LLD-ből generál teljesen azonos konfigokat. Más gyártó eszközén is volt feature, ami már csak API-ból volt kapcsolható. Teljesen korrekt API doksi + mintakódok, nem volt nehezebb feladat, mint egy ismeretlen CLI-ű eszközzel megismerkedni.
Ciscosóknál voltam itthon FirePower meg DC workshopon, ott is nap végére egy jó tananyag alapján probléma nélkül tudtuk API-n keresztül vezérelni a vasakat.
Sajnos általában is az a jellemző, hogy itthon akár egy networkös, akár egy szerveres egy nagyságrenddel kevesebb eszközt tud üzemeltetni az automatizáltság hiánya miatt. (Túl olcsó a munkaerő...) De egy ideális, nyugati szervezben teljesen jól különválasztható a két szakterület, aki a tooling-ot, automatizálást fejleszti nem kell tudnia a network működését, csak a network által megfogalmazott algoritmust lefordítania az adott eszköz/tool nyelvére.
Igazából túl van lihegve kicsit ez a devnet/devops téma, mert nincsenek tele vele a fórumok, nem lehet "kigúglizni". De őszintén szólva aki tud dokumentációt olvasni és érti amit olvas az boldogulni fog vele. -
Yeffy
veterán
akkor/addig mast kerdeznek, uj Udemy course kombo a CCNP-hez ajanlott? eleg jo akcio van ra. ezeknel fix oktato van, vagy verzionkent massal vettek fel? korabban volt itt par oktato, akit ajanlottatok tobben is, azert kerdezem.
ha nem/ezen kivul mit erdemes meg esetleg meghallgatni/reszt venni? termeszetesen OCG utan ertem.
valahol olvastam pl h a Pluralsightnak is vannak jo kurzusai, oket csak hallomasbol ismerem.[ Szerkesztve ]
Big girls ride harder. ヅ || Kondi powaa'!
-
GasparGyozi
lelkes újonc
Sziasztok! Van itt olyan, aki Magyarországon kezdte a hálózatos karrierjét, aztán kiment külföldre?
-
Okean
tag
válasz Cyber_Bird #15690 üzenetére
erdemes legalabb alapszinten megismerkednie egy-ket cloud provider szolgaltatasaival, aki meg most kezdi siman specializalodhat arra
Mit értesz pontosan ez alatt? Jelenleg a CCNA-ra készülök így egyelőre nem egészen világos, hogy hosszú távon milyen irányokban lehet perspektíva.
-
vadger
tag
-
FecoGee
Topikgazda
Nem tudom mennyire mérvadó, én sok éve csináltam már a CCNP-t. Én azt mondanám hogy az OCG legyen az alapod, és ha valamit nem értesz vagy mélyebb ismeretekre van szükség akkor videok/doksik. Könnyű abba a hibába esni, hogy túl sok anyagot nézel és elveszel a részletekben.
-
kenwood
veterán
válasz FecoGee #15739 üzenetére
Redditen sokan panaszkodnak az ENCOR ocgre.
Egyreszt a rengeteg Typo miatt, masreszt azert, mert sok olyan temakor van, ami szerepel a blueprintben, illetve vizsgan is kerdes volt,de az OCG nem targyalja megfelelo melysegben.Ami az ENCOR-hoz ajanlott. Nagyjabol ebben a sorrendben. (nyilvan nem az osszes egyutt)
- INE
- Cisco hivatalos online kurzus
- Boson ( ok adnak linkeket azokhoz a temakhoz, ahol erdemes a Cisco whitepapert is elolvasni)
- itpro.tv
- Linkedin learning
- Pluralsight
- CBT nuggets[ Szerkesztve ]
Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben
-
Yeffy
veterán
-
SnoopDoggOG
csendes újonc
Hello! Másik topicban láttam, hogy egyes IT szakmában teljesen reális pár év tapasztalattal a bruttó 800 ezer - 1 milliós fizetés. A kérdésem az lenne, hogy ebben a szakmában CCNP, vagy CCNP-hez közeli tudással (+pár év tapasztalattal) mennyire számít gyakorinak ez a fizetési sáv?
-
Ripper17
tag
Nekem semmi bajom nincs az OCG-vel, ezek a panaszok (type, meg majd hogy néhány vizsgakérdés nem tiszta) minden ilyen váltásnál ott voltak.
hivatalos online kurzus alatt nem tudom mit ért @kenwood, én hozzánézem amit Ciscos all-in elearning accountal elérek és szerintem gyenge minöségü, pongyola az ENCOR. Sorvezetönek jó... -
Ripper17
tag
válasz SnoopDoggOG #15742 üzenetére
Nem irreális ez a sáv egy medior szinten (5 év körüli, releváns tapasztalat, ami mögött látható fejlödés is van) + CCNP tudással nagyobb cégekben, ha van mögötte soft-skill, projektszemlélet, stb...egy szint és cégméret felett már ezek differenciálnak. öszintén szólva Magyarországon a high-end technológiákra kevés cégnek van pénze, az átlag munkáltatónak többet ér ha az alapokat stabilan tudod + mindenben is tudsz segíteni.
Kisebb cégekböl, Cisco partnerektöl ilyen tapasztalattal ekörüli, bejelentett alapbérek alatt hallok. De ott legtöbbször ezt céges autó, prémium munkaeszközök kompenzálják (ezeket mindenki beárazza hogy neki mennyit ér); míg máshol egyéb bérelemekkel (túlóra, készenlét/ügyelet) összelegózható ez.
Lényeg, hogy kérni kell (persze megalapozottan), a magyar munkáltatók 98%-a a minimális elégségeset fogja csak megadni az után, hogy felvett. És az se fogja zavarni, ha te ott ülsz x éve, bevált ember vagy - simán felvesz az utcáról egy "messziröl jött ember"-t a tiednél magasabb bérért azonos poziba, ha a menedzsmentnek ez a céljait szolgálja. -
fogi
tag
Sziasztok!
Check Point CCSA vizsgát tett valaki mostanában?
Cégnél R80 van, azt is tanultam de a dumpok szerint a vizsgakérdések nagy része R77-re vonatkozik, ami nagymértékben más, minden szempontból. Megtanulni nehéz, mert nem találkoztam vele és felesleges, mert nem is fogok.
Aki esetleg vizsgázott az utóbbi években CCSA R80-ból, kérem ossza meg a tapasztalatait a régi és új változatra vonatkozó kérdések arányával kapcsolatban. Köszönöm és remélem maradhat a kérdés. -
BoneDragon
veterán
Üdv!
Idén megcsináltam a CCNA-t, de elhelyezkedni nem tudtam, sehol nem kerestek juniorokat. Most pár hónapig nem is tudtam foglalkozni az egésszel, család, költözés, blabla és sajnos ahogy nézem most se változott ez ügyben a piac, szintén nem látok junior pozikat. Szeretném a tudásomat felfrissiteni és kicsit fejlődni is. Hol lenne érdemes kezdeni, milyen anyagok vannak erre?
Milyen pozi lehetőségek vannak még ha nem konkrétan network engineernek megyek, de maradni akarok a "közelében", help desk? Kicsit tanácstalan vagyok jelenleg, merre indjuljak el, mert úgy nézem ez a CCNA elég kevésnek tünik jelenleg. Mindenhol seniorokat keresnek. Köszi -
GasparGyozi
lelkes újonc
válasz BoneDragon #15746 üzenetére
Helo. Talán ez jó lehet: Junior Industrial Network Engineer
-
BoneDragon
veterán
válasz GasparGyozi #15747 üzenetére
Attól hogy a nevében benne van, nem tünik túl juniornak.
-
vadger
tag
válasz BoneDragon #15748 üzenetére
Hát pedig szerintem ez pont egy junior állás lehet. Ha van CCNA-d, és esetleg még átnézed az industrial jellegű dolgokat (kezdésnek link egy régi ccna industrial vizsgához), akkor szerintem van ebben lehetőség. Industrial meg olyan dolog, hogy szerintem nem várják el az utca emberétől, hogy profi legyen benne, majd házon belül kitanítják.
CCNA RS, Security és egyéb hálózati témák oktatása: https://ccnaoktatasmagyarul.hu
-
olloczky
senior tag
válasz SnoopDoggOG #15742 üzenetére
Inkább a 800hoz közelebb de igen, teljesen reális.
Úgy még sosem volt, hogy valahogy ne lett volna!
Új hozzászólás Aktív témák
- Kérlek használd a keresőt, mielőtt kérdezel!
- Olvasd el a téma összefoglalót mielőtt kérdezel!
- A dumpok és a warez tiltott témának számítanak!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Yettel topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- exHWSW - Értünk mindenhez IS
- Honor Magic5 Pro - kamerák bűvöletében
- Autós topik
- Milyen billentyűzetet vegyek?
- A használt VGA piac kincsei - Július I
- PlayStation 5
- OLED TV topic
- További aktív témák...
- Amazfit I T-REX 2 I GTS 3 I GTR 3 I GTR 3 Pro
- Új Latitude 7440 2-in-1, FHD+ IPS kihajtható érintő, i7-1365U, 32GB DDR5, 512GB NVMe, IR kamera, gar
- Beszámítás! GB H610M i5 13400F 32GB DDR4 1TB SSD RTX 3070Ti 8GB MONTECH AIR 1000 Lite Corsair 650W
- Xiaomi Instant Photo Printer 1S Set Bontatlan!
- Beszámítás! GB H610M i5 13400F 16GB DDR4 250GB SSD RTX 3070Ti 8GB MONTECH AIR 100 Lite Chieftec 700W