Fórumok
Érkezett egy érdekes feladat. Egy kritikus szoftver fut egy régi SPARC szerveren:
$ version
Machine hardware: sun4u
OS version: 5.10
Processor type: sparc
Hardware: SUNW,Sun-Fire-V440
A szerveren Oracle adatbázisba dolgozó, COBOL-ban írt alkalmazás fut. Ezt az egészet kellene átpakolni AWS-re, Charon Virtual SPARC AMI-ra.
Az amerikai megbízó az alábbi tervet eszelte ki:
Létre kellene hozni egy pont ugyanolyan disk layout-ot az AWS-ben futó gépen, mint ami a SPARC vason van. Majd lementve a SPARC vasat, a mentést vissza kellene állítani az AWS-ben futó emulált SPARC környezetbe.
Majd ha kész, az alábbiak elvártak:
- megfelelő sebességgel futó szoftver
- magas rendelkezésre-állás és üzletfolytonosság
Kérdés:
Csinált már valaki ilyet? Mik a tapasztalatok? :D
Hozzászólások
Pont ilyet nem.
Milyen cobol?
Gábriel Ákos
Van egy ún. SafeTrace development platform, aminek része a COBOL és az Oracle. Pontos verziókra gondolsz?
Ez egy kritikus orvosi környezet. Nagyon nincs helye a gányolgatásnak. Leginkább az érdekelne, hogy mik a valós életből jövő tapasztalatok azoknál, akik csináltak ilyesmit. Van-e értelme nekiállni (mit tud - sebesség, megbízhatóság stb. - ez az emulátor az AWS-ben), lehet-e felelősen ezt elvállalni stb.
trey @ gépház
Ha nincs helye a gányolgatásnak akkor gondolom alapos test-suite is van hozzá.
Microfocus COBOL van Linuxra is, Oracle is.
Én meglépném a konverziót.
Cobol migrációt mainframe-ről Linuxra már csináltam. A Cobol a szopófaktor, az Oracle nem.
Gábriel Ákos
Hali,
Régen elég sok régi sparcot virtualizáltam, az (akkor még) Sun féle LDOM-okba.
Elvileg működhet amit kitaláltak. Az aktuális vas hardware konfigja és az emulált környezet hardware konfigja közti különbség azért tartogathat némi meglepetést.
Sol 10 esetén valószínűleg a saját volume managementje van használva, de ha mondjuk Veritas VM, vxfs, esetleg veritas cluster van, az azért növeli a szopófaktort.
Lehet, hogy egyszerűbb lenne felhúzni az emulált környezetbe is egy Solaris10-et, kb. ugyanarra a patch levelre mint az eredeti, utána átmásolni az Oracle-t, meg a Cobol cuccot rá.
Oracle-ot elég újralinkelni (relink all) a cobol cuccal szerintem nem lesz gond . (Esetleg ha van telepítő készelt, lehet hogy célszerűbb azt is telepíteni az új környezetbe.)
Valószínűleg Microfocus Cobol van rajta. Már nem emlékszem pontosan, de úgy rémlik ott a licenszeléssel kapcsolatban volt általában valami reszelni való.
Joker kérdés: te vállalnád? :)
trey @ gépház
Aha.
Van egy kolléga akivel ketten jó pár ilyen migrációt megcsináltunk. Én már inkább linux vonalon vagyok, de ő a mai napig csinál ilyeneket. Elég jó referenciaák vannak.
Egyeztetek az ügyféllel. Privátban tudnál küldeni nekem referenciákat hasonló melókról?
trey @ gépház
Elvileg működhet amit kitaláltak. Az aktuális vas hardware konfigja és az emulált környezet hardware konfigja közti különbség azért tartogathat némi meglepetést.
Nekem az a tapasztalatom, hogy igazi vasaknál gépcsaládon belül a sima diszktartalom-mozgatás flottul megy, ha változatlan a boot device node (ugyanazt a drivert használó SCSI/FC interfész, ugyanabban a PCI pozícióban, egyező SCSI ID-vel/FCAL loop ID-val). Ha a boot device node-ot változtatni kell, akkor kézi kókányolással, de megy a dolog. Ha viszont gépcsaládok között kéne mozgatni, akkor jellemzően kézi kókányolással sem lehet minden eltérést kiküszöbölni (fel nem települt HW-függő csomagok, device node-ok és társaik), és nem fog rendesen menni.
Valószerűtlennek érzem, hogy azokat a változatos és nem kicsit bonyolult hardvereket valaki egy emulált környezetben mind megcsinálta volna, amik az igazi vasak bootolásánál játszanak.
Lehet, hogy egyszerűbb lenne felhúzni az emulált környezetbe is egy Solaris10-et, kb. ugyanarra a patch levelre mint az eredeti, utána átmásolni az Oracle-t, meg a Cobol cuccot rá.
Ez biztosan jó megoldás, de mindig benne van a pakliban az is, hogy ha nagyon szétkonfigurálták anno a telepítésnél a gépet, és ez nincs atomjól ledokumentálva, akkor ugye vagy észreveszed, hogy mi minden beállítást kell átmásolni, vagy nem.
Nekem anno a legpozitívabb élményeim a Solaris 10 zónákkal voltak, amikor régebbi gépek tartalmát kellett átrakni, konszolidálni. Itt ráadásul a forrás is Solaris 10, ami megkönnyíti ezt az utat (de 9-est és 8-ast is rakták át zónákba). Én tuti ezzel próbálkoznék először.
.
Majd írd meg hogy mi lett... Valami hasonló nálunk is játszhat, mondjuk eddig az újrahúzás mellett és a platform váltás mellett voltunk, de ez egy érdekes opció...
zwei jelezte, hogy szívesen vállalnák a feladatot. Most szervezem az egyeztetést az ügyféllel, amint lesz konkrétum, majd jelzem!
trey @ gépház
...érdekes cucc az a virtual sparc. Akár csak az ára. :)
Mondjuk egy új sparc vas begurítása valószínűleg többe kerülne.
Biztos, hogy akinek nem okoz gondot a COBOL-hoz értő embert megfizetni, annak se a valódi, se a virtuális SPARC árazásával nem lesz gondja :D
Azért várjuk meg, hogy az amerikaiak miért nálunk keresnek erre embert. Remélem nem azért, mert azt hiszik, itt egy marék rizsért meg lehet ezt csináltatni.
Első körben el kell jutnunk majd oda, hogy zwei-ék adnak majd egy árajánlatot a munkára, az ügyfélnek pedig meg kell rendelnie.
trey @ gépház
Az ügyfél megrendelte a munkát, hamarosan kezdődhet a kaland!
trey @ gépház
Rettentően kíváncsi vagyok mi lesz a vége, azért ilyen projektbe szokoevente fut bele az ember
Hamarosan lesz egy meeting zwei és kollégája, valamit az amerikai megbízó és köztem. Akkor pontosodnak a részletek. A nem titkos részt (amit nem érint az NDA) majd itt közzétesszük.
trey @ gépház
subs4news (hátha lesz). Nem hétköznapi történet, kíváncsi vagyok.
echo crash > /dev/kmem
sub
It is up to the customer to review their own licensing agreements. Therefore, Solaris is BYOL for Charon-SSP and customers must make available their own Solaris ISO image for the initial install, after which, the original filesystems from the legacy SPARC system may be migrated.
Van azért szerintem ebben a megoldásban egy kis szürkezóna: a meglevő Sunos vassal érkező "included" Solaris licenc nem terjed ki arra, hogy azt a Solarist BYOL-jelleggel olyan másik vasra másolják át, amit nem a Suntól vettek. Ha a másik vas is a Suntól lenne, akkor nem volna gond, mert az is hozná magával az included Solaris licencét. De ez a virtuális izé nem ilyen, és írják is, hogy nem adnak hozzá Solaris licencet. Más módon viszont csak előfizetés-jelleggel (és már a Sun idejében is erős árazással) lehetett Solaris licenchez jutni. Az Oracle pedig pláne nem arról híres, hogy ilyesmiket olcsón adjon.
Kösz az infót. Erre is rá kell néznünk.
trey @ gépház
Igen ezt én is kiszúrtam, és ez fontos részlet, bár a technikai részét a dolognak nem nagyon befolyásolja.
Az Oracle elvileg támogatja az AWS környezetet, legalábbis az ora adatbázis licenszelési leírásban benne van, hogy AWS esetén hogy kell számolni, de hogy Solarisra mi hogy vonatkozik, az jó kérdés.
Azt nem tartom valószínűnek, hogy ne lehetne teljesen legálisan, fehéren megoldani a dolgot
Tuti biztos meg lehet, a kérdés az, hogy megéri-e.
Én még anno láttam olyan support ajánlatot már az Oracle idejében, egy öregedő gépre, hogy az egy éves supportdíjból vadi új gépre lehetett volna cserélni a régit.
A Sun idejében nem volt ingyenes a Solaris? Vagy az csak az x86 verzió volt?
Mivel sosem létezett olyan Sunos SPARC vas, amire ne lett volna eredendően Solaris licence a vevőnek, így valójában elég volt annyit mondani, hogy a szabadon letölthető verziókat is szabad használni, az eredeti licencfeltételeken túl is (az eredeti feltételek szerint a vashoz járt valamennyi garancia és szoftverkövetés, és ezen időszakban bármilyen megjelenő új verzió szintén "járt", plusz ha volt support szerződés később, akkor arra az időre vonatkozóan is, a támogatás lejárta után megjelentek viszont nem). És emlékeim szerint ennyit mondtak csak. A nem Sunos SPARC vas az egzotikum kategóriájába tartozott még ekkoriban, én pl. csak fényképen láttam olyan SPARC cuccot, amin nem volt Sun logó.
"Mivel sosem létezett olyan Sunos SPARC vas, amire ne lett volna eredendően Solaris licence a vevőnek"
No igen....
"A nem Sunos SPARC vas az egzotikum kategóriájába tartozott"
Fujitsu-Siemens.... úgy rémlik dolgoztam is vele. Nálunk nem nagyon terjedt el, de a németeknél úgy tudom elég sok volt.
Simán csak Fujitsu, és az össszes M-es szériát árulták, és most is van saját SPARC processzoruk.
https://www.hwsw.hu/hirek/57064/fujitsu-sparc-m12-sparc64-xii-oracle-sz…
Nem.
Volt egy vegyesvállalata a Siemensnek és a Fujitsunak (https://en.wikipedia.org/wiki/Fujitsu_Siemens_Computers), mit később a Fuji kivásárolt.
Mainframekben is utaztak, és egy rakás dolgot a mainframe világból beleépítettek a unix dobozaikba. Anno sok-sok éve még mielőtt a Sunt megvette az Ora, majdnem vettünk az akkori céggel egy ilyen high-end vasat, csak végül is a Sun lett a befutó.....máig megvan az akkor ajándékba kapott Fujitsu-Siemens bögrém.
Tudomásom szerint az M szériát amit aztán a
SunOracle is árult eredetileg ők tervezték.Egy óra múlva Teams-meeting a témában. Addig iszok egy kávét :)
trey @ gépház
A móka elkezdődött... majd írok részleteket, addig is:
***************************************************************
Charon-SSP/4U - sun4u VM v4.2.6.aws.market
Copyright (C) 1998-2021 Stromasys S.A. All Rights Reserved.
***************************************************************
sun4u/SPARC V9 (2 X UltraSPARC-II 500MHz), No Keyboard Emulate OBP Rev. 3.18, 1024 MB memory installed, Serial #15756809.
Ethernet address 0:0:4:0:b3:d4, Host ID: 80f06e09.
Type help for more information
ok
:)
Éppen most végeztem a papírokkal. Küldöm a megbízásit és az NDA-t :D
Természetesen, az anonimizált technikai részletek jöhetnek ide!
trey @ gépház
Oké. Természetesen az előző postban a MAC cím és Serial (már) nem él..
Ez volt a teszt kedvéért legyártott legelső Sparc vm, ami egyébként a Solaris installert is bootolni tudta.
A bootot követve eldobtam. Ez még csak a fun factor miatt volt (nem bírtam ki, hogy ne játszak vele alvás előtt.)
Majd beszámolok részletesen a teljes migráció műszaki részéről.
Ez még benne volt a tegnap estében:
:D
Azt gondolnám, hogy a Solaris futni fog, a konténerrel sem lesz baj. Én a sebességre leszek kíváncsi.
trey @ gépház
Hát ott írta: 2 X UltraSPARC-II 500MHz! :D:D:D
Hát, az eredeti se egy rakéta, szóval nem ez lesz a baj. Hanem, hogy az emulátor hogy teljesít. Bár, szerintem egy korszerű Intel CPU-n még emuval is ki kellene jönnie minimum a régi rendszer teljesítményének.
trey @ gépház
Az eredeti V440-ben elvileg 1.5Ghz Ultra sparc IIIi cpu-k vannak. Az még kérdés, hogy hány darab.
Próbáltam összevetni az aktuális processzorokkal a spec.org benchmark alapján, de elég nehéz közös nevezőre hozni őket, mert az Ultrasparc IIIi csak a SPEC CPU 20000-ban van benne
A cpu-t tegnap nem néztem csak ráböktem, hogy kettőt kérek, de pl. az emulált scsi diszkek eredeti product number alapján választhatók...
Átküldtem!
trey @ gépház
Ez egy x86 vason, Linux (CentOS) felett futó SPARC emulátor, ugye?
trey @ gépház
Pontosan. Lehet saját vasra is, onsite telepíteni. Az AWS instace-ban telepítve és konfigolva van.
Vannak ráutaló jelek, hogy mintha az Azure-ban is elérhető lenne.
cool, szerintem ezt hamarosan kipróbálom :) egyelőre ppc64-et próbáltam qemuval, kevés sikerrel.
A licensznek tippre elég húzós ára van, de qemu is tud sparcot...
Update:
Az ügyfél visszajelzése szerint a migráció sikeres volt.
trey @ gépház