ii. architektūra ir infrastruktūros modeliai. Žiniatinklio...

2012

II. Architektūra ir infrastruktūros modeliai.

Žiniatinklio programos projektavimas

Rimantas Kybartas

2011 VU, Matematikos ir informatikos fakultetas

Turinys

• Architektūra

• Infrastruktūros modeliai

– SPI modelis

– Linthicum modelis

• Tinklo architektūra

• Žiniatinklio programa

– Dvigubo fiksavimo problema

– Duomenų bazės rolė


Architektūra


Architektūros komponentai

• Kliento pusėje yra asmeniniai kompiuteriai,

telefonai ir pan.

• Debesis yra didelis tinklas iš serverių ir

asmeninių kompiuterių.

• Tinkle komponentai veikia lygiagrečiai.

• Užduotys turi būti protingai skirstomos.


Veiksmų schema


SPI infrastruktūros modelis

• SPI modelis – labiausiai paplitęs modelis

– Programinė įranga kaip paslauga

– Platforma kaip paslauga

– Infrastruktūra kaip paslauga

• Debesis yra klasė sistemų, kurios teikia IT

resursus nutolusiems vartotojams kaip paslaugą.


SPI išsivystymas ISP kontekste

• ISP teikia interneto paslaugas

• ISP pradėjo teikti papildomas paslaugas (e.

paštas ir pan.)

• Sukurti duomenų centrai klientų duomenim

saugoti

• Programinės įrangos tiekimas (application service

providers)

• ASP išsivystė į debesų kompiuteriją


Įmonių rolės


SPI ir tradicinis modelis

• Įrangos diegimo, palaikymo aspektai

– Įtrauktų įmonės skyrių kiekis

– Techninės ir programinės įrangos kiekis

– Programinės įrangos suderinamumas

– Licencijų kaina

– Veiklos pradžios investicijos

• Saugumo užtikrinimas

– Specialistų samdymas, įrangos poreikis


Linthicum infrastruktūros modelis

• Linthicum modelyje išskirti specifiniai

komponentai.

• Apibrėžia 11 pagrindinių DK technologijos

kategorijų

Linthicum kategorijos

• Saugykla kaip paslauga

• Duomenų bazė kaip paslauga

• Informacija kaip paslauga

• Procesas kaip paslauga

• Programa kaip paslauga

• Platforma kaip paslauga

Linthicum kategorijos

• Integravimas kaip paslauga

• Saugumas bazė kaip paslauga

• Valdymas kaip paslauga

• Testavimas kaip paslauga

• Infrastruktūra kaip paslauga


Linthicum modelis


Tinklo architektūra

Tinklo architektūra svarbi:

• Duomenų centro tinklui (DCN)

• Duomenų centro jungiančiajam tinklui (DCIN)

• Internetui

Duomenų centro tinklas

• Konstruojamas tūkstančio serverių sujungimui

• Hierarchinis tinklo dizainas yra dažniausiaiai

pasitaikantis duomenų centro tinkluose.

• Įprastai naudojama trijų sluoksnių architektūra:

– Prieigos

– Agregavimo

– Branduolio


Duomenų centro tinklas (DCN)

Prieigos lygmuo

• Suteikia prisijungimą prie serverių resursų

• Konstrukcija priklauso nuo sprendimo kriterijų

(serverių tankumo, virtualizacijos ir pan.)

galinčių įtakoti aukštesnių sluoksnių sąsajos

reikalavimus:

– „End-of-row“/„Top-of-rack“/

integruotas/programinis komutatorius

– Plokštieji arba plonieji komutatoriai

Agregavimo lygmuo

• Apibendrinimo taškas sujungiantis prieigos

lygmens komutatorius

• Su prieigos komutatoriais sujungiamas 802.1Q

VLAN kamieninius prievadus, kad serveriai,

priklausantys skirtingiems VLAN ir IP

potinkliams, būtų prijungti prie to paties fizinio

komutatoriaus

Branduolio lygmuo

• Dažnos prieigos ir didelio našumo duomenų

perdavimas tarp duomenų centro ir nuošalios

tinklo briaunos ar magistralinės linijos


DCIN tinklas

• Sujungia kelis duomenų centrus

• DCIN išsivystė kaip speciali tinklų klasė dėl DK

reikalavimų:

– Aukštas pasiekiamumas, nesėkmių išvengimas

– Dinaminis virtualaus serverio migravimas

– Gera telkinių prieiga

– Dinaminis darbų apkrovos balansavimas

– Programos mobilumas tarp skirtingų sričių


Reikalavimai DCIN tinklo

plėtimo projektui

• Aplinkinio sujungimo ciklo išvengimas –

gerinant aukštos prieigos savybę, ryšys turi būti

dubliuojamas

• WAN krūvio balansavimas

• Branduolio skaidrumas

• Kodavimas


Žiniatinklio programa DK

• Lanksti programa, keičianti mastus

• Nėra specifinių standartų ar reikalavimų

• Minimalus reikalavimas – veikimas tarp skirtingų

serverių be problemų

• Problemos netui nieko bendro su pasirinkta

platforma


Žiniatinklio programa


Žiniatinklio programos

problema

• Kelios programos gijos

• Keli serveriai paskirstytoje aplinkoje

• Vienas duomenų šaltinis


Kambario rezervacija. Procesas

1. Užrakinti duomenis, susijusius su kambariu.

2. Patikrinti kambarį, ar jis laisvas.

3. Jei laisvas, pažymėti, kad rezervuotas ir nebėra

laisvas.

4. Atlaisvinti užrakinimą.


Rezervacijos problema


Išsaugotos procedūros

• Procedūros nėra pernešamos iš vienos duomenų

bazės į kitą.

• Jos reikalauja platesnių duomenų bazių

programavimo žinių.

• Jos nepilnai išsprendžia tranzakcijų mastų

keitimą tarp programų serverių kai kuriuose

scenarijuose.

• Nelabai tinkamos atskiriant pavaizdavimą, verslo

modeliavimą, logiką ir duomenis.


Duomenų bazės atsakomybė

• Specialūs laukai:

– Kas užrakino

– Kada užrakino

• Papildomai reikia žiūrėti, kiek laiko užrakinta

Serverių nepasiekiamumas

• Architektūrinis siekis – sutvarkyti vykdymo

aplinką taip, kad vieno serverio sutrikimas

nebūtų svarbus

• Duomenų segmentų palaikymo principas

• Pavyzdžiui, skirtingų viešbučių informacija

saugoma skirtinguose serveriuose

• DK sistemą reikia realizuoti taip, kad nereikėtų

dayti programų serverio atsarginių kopijų


Duomenų segmentai


Apžvalga

• Debesis yra didelis kompiuterių tinklas, kuriame

vartotojams paskirstomi resursai.

• Dažniausiai minimas SPI infrastruktūros

modelis, bet kartais tenka žinoti ir specifinius

Linthicum modelio komponentus.

• Žiniatinklio programa turi išlaikyti duomenų

vientisumą ir veikti tarp kelių serverių, keisdama

mastus.

ii. architektūra ir infrastruktūros modeliai. Žiniatinklio...

Documents