Bare metal SPARC Sun Solaris boxról -> Amazon AWS Charon Virtual SPARC AMI-ra

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

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ó.

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.

Szerkesztve: 2021. 02. 23., k – 09:27

.

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ó...

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

subs4news (hátha lesz). Nem hétköznapi történet, kíváncsi vagyok.

echo crash > /dev/kmem

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.

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

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.
 

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 Sun Oracle 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

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:

ok boot disk1
Boot device: disk1    File and args: -v
module /platform/sun4u/kernel/sparcv9/unix: text at [0x1000000, 0x10a8cb5] data                                                at 0x1800000
module /platform/sun4u/kernel/sparcv9/genunix: text at [0x10a8cb8, 0x1286e77] da                                               ta at 0x1866fc0
module /platform/SUNW,Ultra-4/kernel/misc/sparcv9/platmod: text at [0x1286e78, 0                                               x1286eff] data at 0x18bdb38
module /platform/sun4u/kernel/cpu/sparcv9/SUNW,UltraSPARC-II: text at [0x1286f00                                               , 0x1293307] data at 0x18be240
SunOS Release 5.10 Version Generic_142909-17 64-bit Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved.
Ethernet address = 0:0:4:0:b3:d4
Using default device instance data
mem = 1048576K (0x40000000)
avail mem = 767762432
root nexus = sun4u/SPARC V9 (2 X UltraSPARC-II 500MHz)
pseudo0 at root
.....
Attempting to configure interface hme0...
Skipped interface hme0
Reading ZFS config: done.
Setting up Java. Please wait...
Serial console, reverting to text install Beginning system identification...
Searching for configuration file(s)...
Search complete.
Discovering additional network configuration...


Select a Language

   0. English
   1. Brazilian Portuguese
   2. French
   3. German
   4. Italian
   5. Japanese
   6. Korean
   7. Simplified Chinese
   8. Spanish
   9. Swedish
  10. Traditional Chinese

Please make a choice (0 - 10), or press h or ? for help:

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.)

: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

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

Update:

Az ügyfél visszajelzése szerint a migráció sikeres volt.

trey @ gépház