Hala,
Ha valaki Hanázik (nálam) nagyobb tapasztalattal, kérem segítsen. A közeledő migrálásunk által menekülnénk (nagy verzióugrással) a legújabb cuccra. Új szerver (Dell) és mindegy egyéb rendelkezésre áll, intéztük.
Nomost a jelenlegi szerver (szintén Dell) viszont rendszertelenül köhögni kezdett a hálózati oldalon, a fentebbi műveletet pedig még nem tudjuk meglépni (a nagy verzióugrás a fő nehézség), szóval gyorsban kellene segíteni rajta. Rézről sürgősen át kellene költözni optikára. A gépben ott egy 2xSFP+ kártya, melybe tudok tenni direkt kábelt, amit pedig be tudok húzni a központi routerbe (a szerver oldali SFP a gbic modulokat nagyon válogatja, emiatt 10G modulok és 50/125-ös kábelek nem játszanak, csak a direkt kábel).
Az adatbázisszerver ugyebár figyeli az alatta lévő Linux által kiosztott eszközök neveit, illetve kizárólag a telepítéskor megadott IP-vel hajlandó működni - ami később nem módosítható. Kérdésem: ha kinyírom a most használt RJ45-öket (3db van összedrótozva, szóval mindhármat kinyírom) és az SFP-n adok a gépnek egy olyan címet, amin a 3 "kártya" ült eddig, akkor működni fog a dolog, elérik majd a kliensek? Fontos kérdés, mert éles rendszeren kell doktoráljak. Ha az IP-t visszaírom az elegendő, vagy az eszközazonosító miatt ne is próbáljam?
Köszönöm!
Hozzászólások
HANA-hoz nem értek, de:
Ha 3 RJ45 van összekötve, gondolom bond-al, akkor nem járható út hogy az új SFP-s interfészt is felveszed a bond-ba, az rj45-öket meg kiveszed?
Gondolom a HANA a bond interfész IP-re van konfolva.
Igen, bondolva van - bár nem túl hatékony: a HANA piszok kicsi adatcsomagokkal operál, emiatt a megnövekedett szekvenciális adatmozgás sebessége majdnem lényegtelen, valami 10% sebességnövekedés jön belőle.
Az ötletet köszönöm, ha valaki meg tudná erősíteni éles használatbéli tapasztalattal, azt is megköszönném.
Vortex Rikers NC114-85EKLS
Ebben az esetben mit vartok a 3x1G => 2x10G upgrade-tol?
a bond/LAG bovites futo rendszeren egyebkent bevett gyakorlat, nalam is minden port LAG, meg ha 1 fizikai interface is van benne a startnal
Hibátlan működést várunk, mert a rézzel van valami anomália. Ez a nagyobbik oka a turkálásnak.
Nem tudom az eltérő hálókártyák (integrált 4x/3x RJ45 NIC vs. PERC-es 2x SFP+) milyen reakcióidőt tudnak. Mint írtam HANA esetén nem a folyamatos átviteli sebesség határoz, hanem ezek a fenemód idegesítően apró csomagok. Szóval szerintem tehetném 25 gigás optikára is, majd a központi mikrotikünkbe behúzhatnánk szintén 25-ön, majd 10 gigás gerinceken végigszaladna a teljes vállalaton DE gyanítom sebességre nem lennénk sokkal előrébb a [3x1G szerveroldalon & 10G gerincek] mostani megoldásnál. HANA sajátosság, én pl. falra mászok tőle.
Vortex Rikers NC114-85EKLS
Eddig müködött a rezes kapcsolat, majd hirtelen problémák lépnek fel vele. Milyen változás történt a hálózaton, vagy a szerver oldalon. (pl firmware upgrade, switch csere, stb)
(kevés az info az arhitecktről, pl. a HANA DB és SAP egy szerveren vannak, ha külön vannak, akkor a SAP szerver is 10G fog ülni?, hány kliens használja egyszerre? Mint mond erre a SAP bázis, akinek ezt üzemeltetni kellene)
A rezes kapcsolat instabil: alkalomadtán az IDRAC üzen, hogy link down, majd vissza. Ha kell, többször egymás után. Egyértelmű üzeneteink vannak. R730.
Hálózaton semmi különös nem történt, minden az, ami eddig volt. A 730-as linkek közül talán az egyik vész el az üzenetek szerint, és ez zavar(hat)ja a bondot - ez meg pillanatra ledobja az egészet. Mivel ezek egy "kártyán" vannak, nem egy életbiztosítás - szóval jelenleg egy buta switchbe vannak húzva, mert ott látszólag nem zavarja a klienseket ami történik. Ez a buta switch meg bemegy szintén rézen egy managelt eszközbe, ami 10G-n megy tovább. Szóval tűzoltó üzemmódban vagyunk, nem is kell véleményezni :S
HANA DB a fő gép, süsü Enterprise. A SAP szolgáltatásokat vezérlő szerver külön szerver, azzal nincs gond, tehát ezen a külön szerveren van az RSP. Ez gigás rézen van.
Kb. 80-100 kliens egyszerre, ezek Business One-ok, közvetlenül az adatbáziszeverre cuppannak, néhány egyéb egyedi lightos megoldás szintén közvetlen az adatbázisszerverre kapcsolódik.
HANA DB lógna innentől 10G-n (vagy 2x10G-n), az RSP gép maradna gigán, de ha kell az kiültethető 10G-re. Az SBO kliensek két hoppal érnék el szervert, nincs több köztes kapcsoló, csak egy központi router és a végpontok előtt álló switchek (azok is 10G-vel összekötve). Most három hoppal van meg a kapcsolatok 66%-a.
Akiknek üzemeltetni kellene, azok épp tartalékos üzemmódban vannak még egy ideig, itt jönnénk mi. Köszi!
Vortex Rikers NC114-85EKLS
saptune-nal a hana beálíitasok rá vannak húzva az oprendszerre? Az állít egynéhány hálózati paramétert is. 10G esetén mindenképpen érdemes lesz használni, mert pl. a tcp buffer méretek nem mindegy mekkorák.
Ha jól emlékszem mellanox vagy emulex 10g kártyák ajánlottak hana alá.
saptune az amugy is install time dependency
Holnap leírom, köszi.
Vortex Rikers NC114-85EKLS
Itt vagyok. Amit el tudok mondani:
a.,
Az adatbázisszerver bootol, a felállt Linuxon pedig indul a(z) 1., HDB 2., SAP b1 szervertool 3., b1s.
b., Az RSP gépen (Windows szerver) indul az RSP háttérszolgáltatás.
Ha minden okés, sokhavi uptime várható el ettől a kombótól, újraindítást csupán a mentési szolgáltatás eseti anomáliái indokolnak, de ez az RSP sajátossága. Az adatbázisszerver nyilván certifikált vas (HANA oldalon konfigurált, full kompatibilis azonosítókkal)
c., (ez lesz lényeges neked..)
Ezután cuppan rá a kliens B1-el. Ha szűz klienst telepítünk, akkor ezek a (w10) végpontok kapnak egy SMB/Cifs képességet, majd ráhúzunk egy HDB klienst, és indul a B1 telepítése. Telepítés során automatikusan felkonfigurálja magát nem kevés idő alatt, majd a landscape directory megadása után mehet a műsor.
Minden céleszköz certifikált, az SFP kártya talán nem, mert az utólag került be, részben más céllal. Csipkészletét nézve ez egy intel x520 - viszont a Supermicro tudtommal pl. úgy ad certes vasat, hogy épp ez a hálózati kontroller hajtja.
Vortex Rikers NC114-85EKLS
Semennyire sem értek SAP és Hana környezetekhez, de amit itt a hálózati összekötésekről és konfigurációról írsz, szerintem ott lehet a gond, nem azzal, hogy réz alapú a kapcsolat vagy rossz lenne a szerver egyik rezes portja.
Ha a három bond-olt interfész kábele egy buta switch-be van dugva, akkor nem mindegy milyen mode-ban van a bond. Ellenoldali támogatás nélkül csak az active-passive, balance-tlb és balance-alb módok működőképesek, a többihez kell switch oldali támogatás és konfiguráció is. Ezen felül a bond-ok többségének a lényege, hogy redundanciát (is) adnak (amikor jól vannak konfigurálva mindkét oldalon), szóval egy interfész kiesése nem szabadna semmilyen problémát okozzon (amit a felhasználó már észrevesz).
Vagy esetleg olyan nem lehetséges, hogy az okosabb switch-en (R/M)STP fut, és valami módon az tiltja a kommunikációt időnként, mert neki nem tetsző csomagokat lát a buta switch felől (amit akár egy rossz bond konfig okoz)?
Azt a részt sem értem, hogy ha a 10G szerintetek nem hoz minőségi előrelépést az 1G-hez képesz, akkor miért van most 3x 1G bond? Miért nem csak egy sima 1G (vagy egy active-passive 2x 1G bond)?
Ha 10G-re váltotok, akkor hozhat javulást az alacsonyabb késleltetés esetleg, de ezen cél eléréséhez meg az optikai aktív DAC kábel vagy sima modul+optikai kábel kombó a jobb, nem a rezes DAC kábelek. De ha 2-3 (részben) rezes hop-on jönnek a user-ek és/vagy 1G rézen bármi más szerver app a DB felé, akkor nagyjából tök mindegy, hogy a sorban az utolsó kapcsolat gyorsabb és a késleltetése alacsonyabb...
Ai "(integrált 4x/3x RJ45 NIC vs. PERC-es 2x SFP+)" résznél végleg elvesztettem a fonalat, mert a PERC rövidítés Dell szerverek esetében RAID vezérlőket jelöl, az hogyan jön ide? Nem lehet abban a szerverben egy Fibre Channel HBA kártya esetleg (ami viszont nem lesz jó arra, amire használni szeretnéd)?
Persze ez csak találgatás, de az eddigi elbeszélésedből azt gondolom nem az SFP-re/optikára és/vagy 10G-re váltás lesz a megoldás lényegi összetevője.
A segítő szándékot köszönöm.
Managelt switchekben 4 évig kutya baja volt, most kezdett szarakodni. Az érintett switch 1 éve van alatta (felette), ez a hw uptime is kb ennyi ennél az eszköznél. A szarakodás idején a felügyeleti kártya warningokat küld a három RJ45 egyikének leszakadásáról. Ez a figyelmeztetés nem életbiztosítás, mert az épp jónak mondott többi porttal is lehet gond. Bármi.
Ez látszólag (és eddig) csak az “okos” switchel okoz problémát, kb egy hete (valamivel kevesebb). De ha bedugom egy retek TPLink gigás eszközbe mindhárom kábelt, majd azt viszem tovább egy kábelen az okosba, nincs gond, illetve nem talasztaljuk.
Mivel egy kártyáról jön a három RJ45, szerintem idő kérdése, hogy mind elhaljon. Hacsak nem haldoklik mind, vagy egyáltalán ez a baj.
Fontos, hogy a kb új (egy éves) okos switch 24x RJ45 + 4x SFP+ (vegyesen 1000M és 10G üzemmóddal), minden egyéb bedugott eszköz makulátlan működésű. A switch fullon van, nincs már szabad portja sem és bikajól megy róla minden, akár problémás ipari berendezések is.
Igen, csupán attól, hogy egy HANA adatbázisszerverből 800 csillió gigabittel jössz ki, nem lesz annyival jobb, mint ha egy szar gigás kábellel jönnél ki. Itt a bond/3 ennek ellenőrzésére volt használva (mi sem hittük elsőre), illetve a redundancia miatt maradt meg. Egy jól belőtt hármas bonddal 7-10% javulás nyerhető az SAP kliensek felől mérve, miközben más hasít mint a szar.
Ha infó kell, kérdezz bátran és próbálok válaszolni. Köszi.
Vortex Rikers NC114-85EKLS
De miért reméled azt, hogy az optikai kapcsolat jobb lesz ugyanarra a switchre? Mitől lenne jobb? Ez ilyen technológiai "try and error?"
Mint azt leírtam, ez már a központi routerbe csatlakozna. Ráadásul minden kliensnek egy hoppal kevesebb utat kellene tennie.
Vortex Rikers NC114-85EKLS
Minél több részletet írsz annál inkább hályogkovácsolásnak tűnik nekem az egész. Rá kéne jönni a valódi problémára, ami az eddigiek alapján tippre inkább a TCP rétegben van.
Gábriel Ákos
Dehát leírtam mindent, többször is. Van ami későbbi infó lett ez igaz, de ez nem: ez amire válaszoltál, ezt is leírtam már.
Igen, kovácsolás, leírtam ezt is: tűzoltó üzemmód egyelőre, tűzoltó munkával, én magam is tudom minősíteni.. de a tűzoltómunka genezise már csak ilyen.
Szerintem akkora valószínűséggel bujkál a TCP erdejében a bitmanó, mint nem ott - de rövidesen kiderül kinek volt igaza, mert kiül SFP-re az egész cucc.
Vortex Rikers NC114-85EKLS
Gondolom az iDrac a háromból egy kártyára üzen.
Az nem jó megoldás, ha a 3-ból azt a problémás kártyát kiveszitek (leírásod alapján nem világos, hogy mekkora teljesítmény visszaesést okozna, okozna-e egyáltalán, a mostani szakadozásnál akár az is jobb a migrációig)? (akár elég lehet a kábelt kihúzni és akkor folyamatosan down)
-- nem ide
Vortex Rikers NC114-85EKLS
hana... pfej. egyebkent az IP/device modosulhat, a hostname az ujratelepitos.... arra allit ki kismillio certet.