Mitme klastri Hyperledger Fabric võrgu seadistamine: põhjalik juhend

Blockchain-tehnoloogia on muutnud paljude tööstusharude mängureegleid, pakkudes detsentraliseeritud ja muutumatut andmete säilitamise võimalust, mis lahendab pikaajalisi probleeme andmete terviklikkuse ja usaldusväärsuse valdkonnas.

Paljude kättesaadavate blockchain-raamistike hulgas on Hyperledger Fabric tõusnud esile kui parim lubatud blockchain-rakendus, mida hinnatakse eelkõige selle modulaarse ülesehituse, paindlikkuse ja ettevõtete jaoks sobivuse poolest.

See üksikasjalik juhend käsitleb Hyperledger Fabrici mitme klastri seadistuse loomise keerukat protsessi, mitme klastri ja mitme organisatsiooni Hyperledger Fabrici võrgu ehitamist.

Võrgukomponentide jaotamine erinevate klastrite ja organisatsioonide vahel tagab parema veatolerantsuse, skaleerimisvõime ja organisatsioonilise autonoomsuse.

Iga samm on hoolikalt kirjeldatud, et anda nii tehnilist sügavust kui ka praktilisi teadmisi rakendamiseks.

Enne rakendamise alustamist on oluline mõista käesolevas Hyperledger Fabric arhitektuuri juhendis esitatud arhitektuurilisi aluseid.

Mitme klastri disain on keerukas disain blockchain-võrgu kasutuselevõtuks, mis ühendab koostöö organisatsioonilise sõltumatuse.

Selles arhitektuurimudelis tegeleme kahe erineva organisatsiooniga, millest kummalgi on oma sertifitseerimisasutus, mis vastutab krüptograafiliste identiteetide haldamise ja turvalise autentimise tagamise eest.

Need organisatsioonid tegutsevad iseseisvalt, nende ressursid töötavad erinevates Kubernetes Hyperledger Fabric klastrites.

Selline eraldamine pakub olulisi eeliseid, nagu veatolerantsus, ressursside eraldamine ja asjaolu, et iga organisatsioon saab säilitada kontrolli oma infrastruktuuri üle.

Klastri seadistus on selline, et iga organisatsioon majutab oma pühendatud keskkondades oma rühma võrdväärseid ja sertifikaadi väljastajaid.

Selline disainivalik tagab, et ressursside pärast ei teki konflikte, ning võimaldab organisatsioonidel oma infrastruktuuri vastavalt konkreetsetele vajadustele skaleerida, ilma et see mõjutaks teisi võrgu osalisi.

Tellija teenus, mis toimib võrgu konsensusmehhanismina, on strateegiliselt jaotatud erinevate organisatsioonide vahel.

Kaks tellijat eraldi klastritesse paigutades on arhitektuuril redundantsus ja kõrge kättesaadavus.

Kui ühel tellijal tekib probleeme, jätkab võrk tööd teise tellija kaudu, nii et see ei peatu kunagi.

Rakenduses kasutatakse hoolikalt valitud tööriistu, mis lihtsustavad keeruliste süsteemide kasutuselevõttu ja lisavad tugevaid haldusvõimalusi.

EKS lihtsustab Kubernetes-klastrite kasutuselevõttu, haldamist ja skaleerimist Amazon Web Servicesi infrastruktuuris, pakkudes usaldusväärset ja tõestatud platvormi Fabric-võrgukomponentide hostimiseks.

EKS-i hallatavus tähendab, et see vähendab süsteemi käitamisega seotud kulusid, pakkudes samal ajal ettevõttetasemel usaldusväärsust.

Hlf-Operator on spetsiaalne Kubernetes-operaator, mis on loodud spetsiaalselt Hyperledger Fabric võrkude kasutuselevõtu ja jätkuva töö haldamiseks.

See operaator abstraheerib paljud Fabric-võrkudega seotud keerulised kasutuselevõtu- ja haldusülesanded ning pakub deklaratiivseid konfiguratsioonioptioone, mis muudavad võrgu haldamise palju lihtsamaks ja vähendavad konfiguratsiooni vigade võimalikkust.

Arhitektuuri ja vahendite mõistmise järel järgib rakendamisprotsess struktureeritud sammude jada, mis tuginevad üksteisele, et luua täielikult toimiv võrk.

1. samm: EKS-klastri seadistamine

Rakendamise esimene etapp hõlmab Kubernetes-klastrite loomist, kus asuvad Fabric-võrgu komponendid.

See aluseks olev samm hõlmab hoolikat planeerimist, et tagada klastrite sobiv konfigureerimine plokiahela töökoormuste jaoks.

Klastri konfiguratsioon algab parameetrite määratlemisega, mis reguleerivad klastri käitumist ja võimsust.

Need parameetrid hõlmavad:

• •Instantsitüübid, mis valitakse töökoormuse eeldatavate omaduste alusel
• •Oodatava tehingumahu käsitlemiseks vajalike juhtude arv
• •Kättesaadavuspiirkonnad, mis on valitud vastupidavuse maksimeerimiseks ja latentsuse minimeerimiseks

EKS-klastrite haldamiseks loodud spetsiaalse käsurea tööriista eksctl abil luuakse klastrid vastavalt määratletud spetsifikatsioonidele.

See tööriist automatiseerib palju klastrite varustamisega seotud keerukaid toiminguid, tagades samal ajal parimate tavade järgimise.

Pärast klastrite loomist genereeritakse kubeconfig-failid, et võimaldada turvalist juurdepääsu äsja loodud klastritele.

Need konfiguratsioonifailid sisaldavad järgmiste kasutuselevõtu etappide jaoks vajalikke autentimise andmeid ja ühenduse teavet.

2. samm: Hlf-Operatori ja Istio installimine

Kui klastrid on töövalmis, on järgmine etapp haldustööriistade installimine, mida kasutatakse Fabric-komponentide kasutuselevõtu ja teenustevahelise suhtluse hõlbustamiseks.

Hlf-Operator installimine algab Helm-i repositooriumi lisamisega, mis sisaldab operaatori diagramme.

Kui hoidla on kättesaadav, installitakse operaator mõlemale klastrile, pakkudes Fabric-komponentide haldamiseks vajalikke kohandatud ressursimääratlusi ja kontrollerid.

Järgneb Istio installimine, mis toob klastritesse teenusvõrgu võimalused.

Istio võimaldab mõningaid täiustatud liikluse haldamise, koormuse tasakaalustamise ja jälgitavuse funktsioone, mis on üsna kasulikud hajutatud plokiahela võrkudes, kus on väga oluline komponentide vaheline usaldusväärne suhtlus.

Domeeninimede süsteemi konfiguratsioon määrab nimede struktuuri, mis võimaldab lihtsat suhtlust erinevate klastrite vahel jaotatud võrgukomponentide vahel.

DNS-i seadistamine nõuab AWS Route 53-s hostitud tsooni loomist, et domeen saaks seotud Fabric-võrgustikuga.

Selles hostitud tsoonis on iga teenusekomponendi jaoks loodud eraldi kirjed, mis seovad inimloetavad domeeninimed klastri lõpppunktiga.

Iga peer'i, sertifikaadi väljastaja ja tellija jaoks on määratud CNAME-kirje, mis viitab asjakohasele klastri välisele URL-ile.

See konfiguratsioon võimaldab klastri komponentidel leida ja suhelda teiste klastrite komponentidega, kasutades järjepidevaid ja ennustatavaid domeeninimesid.

DNS-kirjete struktuur:

• •Esimese organisatsiooni puhul luuakse kirjed sertifikaadi väljastaja ja võrdväärsete osapoolte jaoks
• •Teisel organisatsioonil peab olema oma andmekogu
• •Tellijaorganisatsioon nõuab oma sertifitseerimisasutuse ja mitme tellija jaoks andmeid, mis viitavad nende vastavatele klastri lõpppunktidele.

Kui infrastruktuur ja võrgustik on paigas, algab tegelike Fabric-komponentide kasutuselevõtt sertifitseerimisasutuste ja iga organisatsiooni võrdväärsete osapooltega.

Sertifitseerimisasutused on oma organisatsioonide usaldusankrud ja väljastavad krüptograafilisi identiteete, mida osalejad kasutavad võrgus toimingute autentimiseks ja autoriseerimiseks.

Iga organisatsioon rakendab oma CA-d spetsifikatsioonide alusel, mis hõlmavad registreerimise volitusi, TLS-konfiguratsiooni ja muid turvaparametreid.

Peers on tehingute töötlemise sõlmed iga organisatsiooni sees.

Need komponendid hoiavad raamatupidamisregistri koopiaid, käitavad ketikoodi ja kinnitavad tehinguid võrgu kinnitamiseeskirjade alusel.

Peer-rakendamine – CA rakendamiseks määratakse kindlaks salvestusruumi nõuded, ressursside jaotamine ja ühenduvuse seaded.

Esimese organisatsiooni puhul:

• •Esmalt rakendatakse CA ja seejärel peer-sõlmed
• •Konfiguratsioonifailid määravad kindlaks iga komponendi konkreetsed parameetrid, nagu bootstrap-identiteedid, salvestusklassid ja teenusetüübid
• •Pärast nende konfiguratsioonide rakendamist jälgitakse komponente, kuni need on valmisolekus

Teisel organisatsioonil on sarnane kasutuselevõtu mudel, kus CA ja selle võrdluspartnerid on konfigureeritud vastavalt organisatsiooni spetsiifilistele nõuetele.

Kuigi üldine protsess on sarnane esimese organisatsiooni omaga, erinevad mõned konfiguratsiooniväärtused, et kajastada eraldi klastri ja domeeni konfiguratsioone.

Tellijaorganisatsioonil on võrgustikus eriline roll, kuna see pakub konsensusmehhanismi, mida kasutatakse tehingute järjestamiseks ja plokkide loomiseks, mis jaotatakse võrdsetele osapooltele.

Tellija CA loomine loob sertifikaadi väljastaja, kes vastutab identiteetide väljastamise eest tellija sõlmede jaoks.

See CA on organisatsiooni CA-dest lahti seotud ja tugevdab tellimusteenuse tellimuste ja tehingute kinnitamise eraldatust.

Esimene tellija rakendatakse konfiguratsiooniga, mis määrab:

• •Selle seos tellijaga CA
• •Salvestusnõuded
• •Genesis-ploki seaded

See tellija on tellimusteenuse esimene ankur.

Teise tellija kasutuselevõtt lisab täiendava keerukuse taseme, kuna see tellija asub eraldi klastris.

Tehtud on järgmised konkreetsed muudatused:

• •CA host viited osutavad tellija CA domeenile
• •CA host lisatakse sertifikaadi allkirjastamise taotlusele
• •CA TLS-sertifikaadid kopeeritakse esimese tellija konfiguratsioonist

Need kohandused tehakse selleks, et teine tellija saaks tellimusteenuse CA-d õigesti autentida ja sellega suhelda.

Pärast konfiguratsiooni kohandamist rakendatakse teine tellija ja jälgitakse seda kuni töövalmiduseni.

Selles etapis on võrgustikul olemas täielik põhitaristu komponentide komplekt, kus kõik CA-d, peerid ja tellijad töötavad ja on kättesaadavad.

Hyperledger Fabric kanalid pakuvad privaatseid suhtluskanaleid konkreetsete võrgustiku osaliste vahel, võimaldades konfidentsiaalseid tehinguvooge ja valikulist andmete jagamist.

Kanali loomine algab iga organisatsiooni ja tellijaorganisatsiooni haldusidentiteetide registreerimise ja registreerimisega.

Nendel identiteetidel on kanalite haldamise toimingute tegemiseks vajalikud õigused.

Registreerimiseks on vaja:

• •Ühendage asjaomase CA-ga
• •Luua kasutajakontosid haldusõigustega

Pärast registreerimist loob registreerimine krüptograafilised materjalid iga identiteedi jaoks (allkirjastamissertifikaadid ja privaatsed võtmed).

Kui kõik haldusidentiteedid on valmis, koondatakse need Kubernetes-saladusse, millele viidatakse kanali toimingute käigus.

See salajane pakett sisaldab kanalite haldamiseks vajalikke krüptograafilisi materjale.

Peakanal algatatakse spetsifikatsioonidega, mis määratlevad:

• •Osalevad organisatsioonid
• •Kanalite eest vastutavad tellijad
• •Kanalite toimimist ja muudatusi reguleerivad eeskirjad

See algatamisprotsess loob kanali algbloki ja kanali konfiguratsiooni.

Mõlema organisatsiooni töötajad liituvad kanaliga, viidates peamise kanali konfiguratsioonile ja lisades oma organisatsiooni volitused.

See ühinemisprotsess muudab kanali nähtavaks võrdväärsete jaoks ja võimaldab neil vastu võtta plokke, mis sisaldavad kanali tehinguid.

Jälgijate kanalid luuakse iga organisatsiooni jaoks, et luua ühendus kolleegide ja kanali vahel.

Need konfiguratsioonid sisaldavad teavet selle kohta, milline peer peaks millist kanalit järgima, ja täiendavad ahela liikmelisuse seadistust.

Chaincode, Hyperledger Fabrici nutikas leping rakendus, on äriloogika, mis kirjeldab tehingute töötlemist ja seisundi haldamist plokiahelas.

Chaincode'i elutsükkel algab chaincode'i pakendamisega rakendatava artefaktina.

Selles rakenduses kasutatakse ketikoodi teenusena, mis nõuab järgmist:

• •Ketikoodi sisaldava Docker-pildi loomine
• •Valmistage ette ühenduse metaandmed, mis kirjeldavad, kuidas võrdväärsed osapooled peaksid ühenduma ketikooditeenusega.

Esimese organisatsiooni puhul:

• •Pakendatud kettakood installitakse peer'ile, muutes kettakoodi paketi kättesaadavaks kasutuselevõtuks
• •Valmistatakse ette ühenduse konfiguratsioonifail, mis sisaldab aadressi ja TLS-ühenduse üksikasju ketikooditeenuse jaoks.
• •Seejärel rakendatakse kettkood Kubernetes-teenusena organisatsiooni klastris, muutes selle kättesaadavaks organisatsiooni partneritele.

Pärast ketikoodi määratluse kasutuselevõttu kiidab organisatsioon ketikoodi määratluse heaks, mis tähendab, et see ketikoodi versioon on valmis kanalil kasutamiseks.

Kui kõik organisatsioonid on ketikoodi määratluse heaks kiitnud, salvestatakse see kanalisse, mis muudab selle aktiivseks ja valmis kasutamiseks.

See kinnitamisprotsess loob ketikoodi konteineri ja muudab selle kanali jaoks autoriteetseks rakenduseks.

Teine organisatsioon läbib sarnase installimisprotsessi ja installib sama chaincode-paketi oma peeridele ning rakendab chaincode-teenuse oma klastris.

Pärast installimist ja kasutuselevõttu on ketikood valmis kasutamiseks kogu võrgus.

Kui kõik komponendid on paigaldatud ja konfigureeritud, tagab kontrollimine, et võrk töötab ettenähtud viisil ja suudab tehinguid korrektselt töödelda.

Tehingute testimine hõlmab näidistehingute algatamist, mis rakendavad ketikoodi loogikat.

Need tehingud on:

• •Esitada kolleegidele, kes simuleerivad tehingu täitmist ja tagastavad tehingule kinnitused
• •Saadetakse tellimusteenusele, mis järjestab need plokkideks ja saadab need kõikidele kanali liikmetele

Tehingute edukas töötlemine tagab, et:

• •Peer-to-peer-suhtlus toimib korralikult
• •Toetuspoliitika rakendatakse nõuetekohaselt
• •Tellimusteenus järjestab tehingud asjakohaselt
• •Riigi muudatused kajastuvad korrektselt kõigis võrdsetes

Mitme klastri ja mitme organisatsiooniga Hyperledger Fabric võrgu loomine nõuab hoolikat planeerimist, täpset konfigureerimist ja paljude komponentide ja tööriistade koordineerimist.

Protsess hõlmab järgmist:

• •Eraldatud, kuid ühendatud infrastruktuuri loomine
• •Rakendage spetsialiseeritud plokiahela elemente
• •Turvaliste sidekanalite seadistamine
• •Kontrollige nõuetekohast toimimist tehingute testimise abil.

Selline arhitektuuriline lähenemine pakub järgmisi eeliseid:

• •Parandatud veatolerantsus komponentide jaotamisega võrgus
• •Parandatud skaleeritavus organisatsiooni ressursside eraldamise abil
• •Suurenenud organisatsiooniline kontroll infrastruktuuri ja operatsioonide üle
• •Suurem paindlikkus võrgu kohandamiseks vastavalt muutuvatele nõuetele

Selle tulemusena tekkinud plokiahela infrastruktuur on tugev alus, mida saab kasutada mitmesugusteks rakendusteks erinevates tööstusharudes, alates tarneahela jälgimisest kuni finantstehingute arveldamiseni ja tervishoiudokumentide haldamiseni.

Hyperledger Fabrici lubatud olemus koos mitme klastri arhitektuuriga pakub platvormi, mis tasakaalustab plokiahela läbipaistvuse ja muutumatuse ettevõtte rakenduste privaatsuse ja kontrolli nõuetega.

On mitmeid täiustusi, mida võiks teha, et veelgi parandada kasutuselevõtu protsessi ja laiendada võrguarhitektuuri võimekust.

Automatiseerimine on oluline võimalus parendamiseks.

Skriptide ja infrastruktuuri-koodina mallide arendamist võiks kasutada järgmistel eesmärkidel:

• •Lihtsustage seadistamisprotsessi
• •Minimeerige käsitsi konfigureerimise samme
• •Minimeerige inimliku vea võimalus

Selline automatiseerimine võimaldaks võrku korduvamalt kasutusele võtta ja muuta see kättesaadavaks organisatsioonidele, kellel on erinev teadmiste tase blockchaini kohta.

Mitme pilve rakenduste suurem toetamine muudaks võrgu vastupidavamaks ja paindlikumaks.

Erinevate organisatsioonide paigutamine erinevate pilvepakkujate juurde, näiteks ühe organisatsiooni paigutamine AWS-i, teise Google Cloud Platformi ja kolmanda Microsoft Azure'i, tagaks, et ühe pilve piires ei tekiks sõltuvusi, kuid organisatsioonid saaksid kasutada oma lemmikpilve keskkondi, osaledes samal ajal ühtses plokiahela võrgustikus.

Need täiustused tugineksid praeguse rakenduse tugeval alusel, laiendades võrgu võimekust ja muutes selle veelgi sobivamaks tootmisettevõtete rakenduste jaoks.