-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
721 lines (718 loc) · 100 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="it-IT" xml:lang="it-IT">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="generator" content="pandoc" />
<meta name="author" content="Dave Null" />
<title>Appunti del corso di calcolo ad alte prestazioni</title>
<style type="text/css">code{white-space: pre;}</style>
<link rel="stylesheet" href="main.css" type="text/css" />
</head>
<body>
<div id="header">
<h1 class="title">Appunti del corso di calcolo ad alte prestazioni</h1>
<h2 class="author">Dave Null</h2>
</div>
<div id="TOC">
<ul>
<li><a href="#sommario">Sommario</a></li>
<li><a href="#licenze">Licenze</a></li>
<li><a href="#teoria-dei-calcolatori-e-del-calcolo-scientifico">Teoria dei calcolatori e del calcolo scientifico</a><ul>
<li><a href="#modello-di-von-neumann">Modello di Von Neumann</a></li>
<li><a href="#tassonomia-di-flynn">Tassonomia di Flynn</a></li>
<li><a href="#setihome">SETI@home</a></li>
<li><a href="#cluster">Cluster</a></li>
<li><a href="#batch-system">Batch System</a></li>
</ul></li>
<li><a href="#principi-di-sicurezza">Principi di sicurezza</a><ul>
<li><a href="#algoritmi-di-crittografia-simmetrica-e-asimmetrica">Algoritmi di crittografia simmetrica e asimmetrica</a></li>
<li><a href="#firma-digitale">Firma digitale</a></li>
<li><a href="#certificati-personali-secondo-lo-standard-x.509">Certificati personali secondo lo standard X.509</a></li>
</ul></li>
<li><a href="#grid-computing">Grid Computing</a><ul>
<li><a href="#principi-di-calcolo-a-grid">Principi di calcolo a Grid</a></li>
<li><a href="#sottomissione-di-job-ad-una-grid">Sottomissione di job ad una Grid</a></li>
<li><a href="#gestione-della-sicurezza-in-grid">Gestione della sicurezza in Grid</a></li>
</ul></li>
<li><a href="#cloud-computing-storage">Cloud Computing & Storage</a><ul>
<li><a href="#virtualizzazione">Virtualizzazione</a><ul>
<li><a href="#tipi-di-virtualizzazione">Tipi di virtualizzazione</a></li>
<li><a href="#vantaggi-della-virtualizzazione">Vantaggi della virtualizzazione</a></li>
<li><a href="#svantaggi-della-virtualizzazione">Svantaggi della virtualizzazione</a></li>
</ul></li>
<li><a href="#cloud-computing">Cloud Computing</a><ul>
<li><a href="#traditional-infrastructure-model">Traditional infrastructure model</a></li>
<li><a href="#definizione-di-cloud-computing">Definizione di cloud computing</a></li>
<li><a href="#service-models">Service models</a></li>
<li><a href="#infrastructure-as-a-service">Infrastructure as a Service</a></li>
<li><a href="#platform-as-a-service">Platform as a Service</a></li>
<li><a href="#software-as-a-service">Software as a Service</a></li>
<li><a href="#alcuni-esempi-di-service-models">Alcuni esempi di service models</a></li>
<li><a href="#deployment-and-isolation-models">Deployment and isolation models</a></li>
<li><a href="#considerazioni">Considerazioni</a></li>
</ul></li>
<li><a href="#cloud-storage">Cloud Storage</a><ul>
<li><a href="#esempi-di-tecnologie-disponibili-per-il-cloud-storage">Esempi di tecnologie disponibili per il cloud storage</a></li>
<li><a href="#caratteristiche-di-un-cloud-storage">Caratteristiche di un cloud storage</a></li>
</ul></li>
</ul></li>
<li><a href="#analisi-di-big-data">Analisi di Big Data</a><ul>
<li><a href="#apache-hadoop">Apache Hadoop</a></li>
<li><a href="#hdfs">HDFS</a><ul>
<li><a href="#scrittura-di-file-in-hdfs">Scrittura di file in HDFS</a></li>
</ul></li>
<li><a href="#map-reduce">Map Reduce</a></li>
</ul></li>
</ul>
</div>
<h2 id="sommario">Sommario</h2>
<p>In questo documento sono raccolti gli appunti del corso <em>“Calcolo ad Alte Prestazioni per la Fisica”</em>, tenuto dal professor Giacinto Donvito al dipartimento interateneo di Fisica dell’Università degli studi di Bari nell’anno accademico 2015/2016.</p>
<p>Per la parte di strumenti per il calcolo scientifico si rimanda al manuale <em>Amministrare GNU/Linux</em> di S. Piccardi, distribuito con licenza GNU Free Documentation License (FDL) all’indirizzo:</p>
<p><a href="https://labs.truelite.it/attachments/download/821/corso.pdf" class="uri">https://labs.truelite.it/attachments/download/821/corso.pdf</a></p>
<p>ed in particolare, con riferimento alla revisione 1367 del 9/07/2014, ai capitoli 1, 2, 6 ed i paragrafi 4.1, 4.2, 4.3, 5.1 (ed eventualmente del 8.3).</p>
<p>Una utile introduzione sull’utilizzo di <code>make</code> si trova nella appendice “Gli strumenti di ausilio per la programmazione” di <em>Guida alla Programmazione in Linux</em> (GaPiL) sempre di S. Piccardi e distribuita anch’essa con licenza FDL all’indirizzo</p>
<p><a href="http://gapil.gnulinux.it/files/2011/12/gapil.pdf" class="uri">http://gapil.gnulinux.it/files/2011/12/gapil.pdf</a></p>
<p><strong>ATTENZIONE:</strong> Questo documento viene distribuito nella speranza possa essere utile, tuttavia non è garantita la correttezza dei contenuti o della forma. Sono ben gradite segnalazioni di eventuali errori.</p>
<h2 id="licenze">Licenze</h2>
<p>Il contenuto di questo documento è rilasciato sotto licenza Creative Commons Attribution 4.0 International.</p>
<p>The content of this document is licensed under a Creative Commons Attribution 4.0 International License. To view a copy of this license, visit</p>
<p><a href="http://creativecommons.org/licenses/by/4.0/">http://creativecommons.org/licenses/by-sa/4.0/</a></p>
<h1 id="teoria-dei-calcolatori-e-del-calcolo-scientifico">Teoria dei calcolatori e del calcolo scientifico</h1>
<h2 id="modello-di-von-neumann">Modello di Von Neumann</h2>
<p>Praticamente tutti i computer attuali fondano la propria architettura sul <em>modello di Von Neumann</em>, quest’ultimo si basa sul principio secondo cui i dati e le istruzioni condividono lo stesso spazio di memoria. Lo schema è il seguente, ci sono 5 unità fondamentali:</p>
<ol style="list-style-type: decimal">
<li><strong>CPU (o unità di lavoro)</strong> che si divide a sua volta in</li>
</ol>
<ul>
<li><strong>Unità di controllo</strong>, che gestisce le operazioni necessarie per eseguire una istruzione o un insieme di istruzioni</li>
<li><strong>Unità operativa</strong>, la cui parte più importante è l’unità aritmetico-logica (o ALU) e che effettua appunto operazioni aritmetiche e logiche</li>
</ul>
<ol start="2" style="list-style-type: decimal">
<li><strong>RAM (Random Access Memory)</strong>: Unità di memoria, intesa come memoria di lavoro o memoria principale</li>
<li><strong>Unità di input</strong> (tastiere, mouse, ecc.)</li>
<li><strong>Unità di output</strong> (monitor, stampanti, plotter, ecc.)</li>
<li><strong>Bus</strong> ovvero un canale che collega tutti i componenti fra loro</li>
</ol>
<p>In un calcolatore convenzionale le istruzioni vengono processate <strong>sequenzialmente</strong> nei seguenti passi:</p>
<ol style="list-style-type: decimal">
<li>un istruzione viene caricata dalla memoria (fetch) e decodificata</li>
<li>vengono calcolati gli indirizzi degli operandi</li>
<li>vengono prelevati gli operandi dalla memoria</li>
<li>viene eseguita l’istruzione</li>
<li>il risultato viene scritto in memoria (store)</li>
</ol>
<p>Esistono pertanto due strategie per migliorare le performance</p>
<ul>
<li>Aumentare le prestazioni dei singoli componenti elettronici</li>
<li>Eseguire più istruzioni contemporaneamente</li>
</ul>
<p>Si precisa che in generale un piccolo aumento delle performance non è interessante da un punto di vista tecnologico e pertanto si considera un incremento significativo intorno ad un ordine di grandezza (fattore 10).</p>
<p>La prima strategia ha dei limiti fisici:</p>
<ul>
<li>Problema della dissipazione del calore</li>
<li>Limite imposto dalla velocità della luce</li>
</ul>
<p>Il problema della dissipazione del calore è collegato alla dimensione dei transistor che compongono la CPU, questa dimensione è a sua volta collegata alle dimensioni caratteristiche del processo di litografia utilizzato (<em>feature dimension</em>). Il limite attuale per queste dimensioni è intorno ai 10 nanometri e non è possibile scendere molto al disotto di questa dimensione per via di effetti quantistici (oltre naturalmente al limite imposto dalle dimensioni atomiche del supporto di silicio).</p>
<p>L’altro limite è la velocità di I/O che è vincolata al limite fisico della velocità della luce per i segnali elettromagnetici nel vuoto.</p>
<p>Altri problemi sono la dimensione della ram, che pone un limite alle applicazioni in esecuzione (attualmente su un singolo slot 128GB), la larghezza di banda tra memoria e processore, o fra processore/memoria e I/O, la larghezza di banda della cache, ecc.</p>
<h2 id="tassonomia-di-flynn">Tassonomia di Flynn</h2>
<p>La prima forma di parallelismo sperimentata è il <strong>pipelining</strong> e presenta delle analogie con il concetto di catena di montaggio dove, in una linea di flusso (pipe) di stazioni di assemblaggio gli elementi vengono assemblati a flusso continuo.</p>
<p>In questo caso le componenti elettroniche specializzate (unità) che operano su ciascuna delle 5 fasi attraverso cui viene eseguita una istruzione (dal fetch allo store) funzionano simultaneamente. Ciascuna lavora sulla istruzione seguente rispetto alla unità successiva e sulla istruzione precedente rispetto alla unità precedente. In questo modo si evitano i tempi morti sulle singole unità.</p>
<p>Idealmente tutte le stazioni di assemblaggio devono avere la stessa velocità di elaborazione, altrimenti la stazione più lenta diventa il <em>bottleneck</em> della intera pipe.</p>
<p>La tassonomia di Flynn è una classificazione delle molteplicità dell’hardware per manipolare stream di istruzioni e di dati. In particolare lo <strong>stream delle istruzioni</strong> (sequenza delle istruzioni eseguite dal calcolatore) può essere singolo, <strong>SI</strong> per Single Instruction stream, o multiplo, <strong>MI</strong> per Multiple Instruction stream, ed anche lo <strong>stream di dati</strong> (sequenza degli operandi su cui vengono eseguite le istruzioni) può essere a sua volta singolo, <strong>SD</strong> per Single Data stream, o multiplo, <strong>MD</strong> per Multiple Data stream. Complessivamente sono possibili 4 combinazioni:</p>
<ul>
<li><strong>SISD</strong>: è la tipica architettura di Von Newman (sistemi scalari mono-processore) e può essere pipelined</li>
<li><strong>MISD</strong>: più flussi di istruzioni lavorano contemporaneamente su un unico flusso di dati. Non è stata finora utilizzata praticamente.</li>
<li><strong>SIMD</strong>: una singola istruzione opera simultaneamente su più dati, in questo caso il sistema possiede una singola unità di controllo ma diverse unità di elaborazione. Sistemi di questo genere vengono anche chiamati <em>array processor</em> o <em>sistemi vettoriali</em>. Anche questo genere di sistemi può essere pipelined. Esistono esempi famosi di supercomputer vettoriali (come quelli costruiti dalla Cray negli anni 70) e sviluppati per applicazioni particolari, oggi molti dei moderni processori hanno capacità SIMD ed un set di istruzioni dedicato (SSE, Streaming SIMD Extensions, nel caso Intel).</li>
<li><strong>MIMD</strong>: in questo caso si parla anche di parallelismo asincrono ed esistono più CPU che operano su dati diversi, ovvero più unità di controllo ciascuna collegata a più unità operative. In questo senso ci si può riferire a questi sistemi come ad una versione multiprocessore dei sistemi SIMD.</li>
</ul>
<p>Per realizzare sistemi MIMD è necessario che i vari sottosistemi comunichino tra loro. Questo può avvenire sia in un solo calcolatore con <strong>un’unica memoria condivisa</strong> fra più processori (per questo detti <em>tightly coupled</em>), che per questo devono trovarsi nello stesso spazio fisico, sia tramite una rete di calcolatori (con processori in questo caso <em>loosely coupled</em>) interconnessi e funzionalmente completi (dotati di CPU, RAM, bus, dischi, etc.), che possono anche trovarsi in posti geograficamente differenti. Inoltre sono anche possibili soluzioni combinate di questi due casi.</p>
<p>I sistemi di tipo MIMD abbracciano una ampia classe di architetture possibili, ricapitolando si ha</p>
<ul>
<li><strong>Architettura MIMD multiprocessore o shared memory system</strong>: i processori condividono i dati e le istruzioni in una memoria centrale comune. La comunicazione avviene dunque mediante condivisione della memoria attraverso un bus.</li>
<li><strong>Architettura MIMD multi-computer o distributed memory system</strong>: ogni processore ha una memoria propria. I vari processori comunicano tra loro mediante una rete che consente a ciascun processore di trasmettere e ricevere dati dagli altri. I processori possono anche essere fisicamente lontani.</li>
</ul>
<p>Inoltre il genere di calcoli che vengono eseguiti su un sistema parallelo può essere di due tipi, distinti per il genere di priorità che comportano e di performance richieste al sistema</p>
<ul>
<li><strong>HPC, High Performance Computing</strong>: il calcolo HPC consiste nell’esecuzione di <em>task</em> computazionalmente intensivi nel minor tempo possibile ed è dunque caratterizzato dalla necessità di grandi capacità di calcolo distribuite in brevi periodi di tempo (ore o giorni). Le performance di sistemi per HPC sono spesso misurate in <em>FLOPS</em> (FLoating point OPerations per Second).</li>
<li><strong>HTC, High Throughput Computing</strong>: il calcolo HTC consiste usualmente nell’esecuzione di molti task debolmente correlati (o di singoli task su grandi moli di dati) che si ha interesse siano completati efficientemente lungo periodo (mesi o anni).</li>
</ul>
<p>La velocità della condivisione di istruzioni e dati caratteristici dei sistemi a memoria condivisa contro la flessibilità e la scalabilità dei sistemi a memoria distribuita tendono in maniera naturale a far identificare i primi come soluzioni per HPC ed i secondi per HTC.</p>
<p>Anche in questo caso (specialmente nel caso di grandi sistemi) questi paradigmi possono combinarsi (ad esempio i sottosistemi di una infrastruttura per HTC possono essere effettivamente sistemi HPC).</p>
<h2 id="setihome">SETI@home</h2>
<p>SETI@home è stato un progetto per la ricerca di segnali radio compatibili con segni di vita intelligente extraterrestre. Questo progetto è stato tra i primi e più famosi ad essersi avvalsi di una infrastruttura di calcolo distribuito <em>volontario</em> basata su internet, ovvero ad aver utilizzato le risorse, momentaneamente e gratuitamente messe a disposizione, di personal computer geograficamente distribuiti e connessi ad un nodo centrale tramite una connessione internet.</p>
<p>Oggi parte della tecnologia sviluppata per SETI@home è confluita in una infrastruttura per il calcolo distribuito indipendente dal particolare progetto di ricerca denominata BOINC (Berkeley Open Infrastructure for Network Computing). Tramite quest’ultima gli utenti possono decidere di donare il proprio tempo di CPU ad uno o più progetti. Lo stesso SETI@home prosegue oggi come uno dei progetti ospitati da BOINC.</p>
<p>Nel caso di SETI@home l’obiettivo era analizzare tutto lo spettro delle frequenze di un radio telescopio per l’intero tempo di osservazione. Ciò che ha reso possibile l’impiego della infrastruttura di calcolo descritta</p>
<ol style="list-style-type: decimal">
<li>I dati possono essere spacchettati in piccole porzioni (dell’ordine di 500 KByte), non è pertanto necessaria una connessione ad alte performance fra i singoli nodi.</li>
<li>Il tempo di CPU necessario per analizzare tali porzioni di dati su hardware di consumo è relativamente breve.</li>
<li>L’analisi dei segnali in ciascuna porzione è del tutto indipendente dalle altre ed è pertanto possibile eseguire tutti i job contemporaneamente (si dice che il problema è <em>embarrassingly parallel</em> o <em>perfectly parallel</em>).</li>
</ol>
<h2 id="cluster">Cluster</h2>
<p>Un gruppo di calcolatori interconnessi ed in grado di lavorare cooperativamente come un unico sistema è in genericamente indicato come <em>cluster</em>.</p>
<p>Perché un cluster possa essere considerato come un sistema a memoria distribuita è necessario:</p>
<ul>
<li>hardware di rete ad elevate prestazioni</li>
<li>uno strato software che implementi le funzionalità richieste (interfacce, protocolli, librerie, etc.)</li>
<li>applicativi che sfruttino le capacità del sistema</li>
</ul>
<p>Un esempio di queste librerie è MPI (Message Passing Interface) che permette di implementare in diversi linguaggi (C, C++, Fortran, Python, Julia) applicativi per sistemi a memoria distribuita. L’ovvia premessa è che, indipendentemente dal sistema particolare o dal linguaggio di programmazione, l’algoritmo sia parallelizzabile.</p>
<p>In generale esistono tre tipi di cluster (i primi due sono i più diffusi):</p>
<ol style="list-style-type: decimal">
<li><strong>Fail-over Cluster</strong>: il funzionamento delle macchine è continuamente monitorato e quando una di queste ha un malfunzionamento un’altra subentra in attività.</li>
<li><strong>Load Balancing Cluster</strong>: è un sistema nel quale le richieste di lavoro sono inviate alla macchina con meno carico di elaborazione distribuendo/bilanciando così il carico di lavoro sulle singole macchine.</li>
<li><strong>HPC Cluster</strong>: le macchine suddividono l’esecuzione di un <em>job</em> in più processi e questi ultimi vengono istanziati simultaneamente su più macchine (calcolo distribuito).</li>
</ol>
<p>In generale i vantaggi offerti da un cluster rispetto ad un singolo calcolatore sono</p>
<ul>
<li><em>Incremento delle capacità di calcolo</em> grazie allo sfruttamento di più unità di calcolo e maggiore disponibilità di memoria</li>
<li><em>Maggiore affidabilità</em> in quanto il sistema continua a funzionare anche in caso di guasti di parti di esso (ovvero dei singoli calcolatori)</li>
<li><em>Minori costi</em>, infatti questi sistemi sono fino a 15 volte più economici dei tradizionali supercomputer rispetto ai quali, a parità di prestazioni, permettono un notevole risparmio sui componenti hardware</li>
<li><em>Scalabilità hardware</em>, possibilità di aggiungere ho rimpiazzare singole componenti a caldo</li>
<li><em>Disponibilità di un gran numero di software Open Source</em> come MOSIX e openMosix.</li>
</ul>
<p>Gli svantaggi principali sono:</p>
<ul>
<li>Difficoltà di gestione e di organizzazione di un elevato numero di calcolatori</li>
<li>Possibilità di problemi di connessione e di banda passante (specialmente di calcolatori lontani)</li>
<li>Assieme allo hardware scala anche la probabilità di failure</li>
<li>Scarse prestazioni nel caso di applicazioni non parallelizzabili</li>
</ul>
<p>Fra i primi cluster si ricordano i cluster Beowulf, ovvero cluster di semplici personal computer collegati tramite reti informatiche standard, senza l’utilizzo di hardware esplicitamente sviluppato per il calcolo parallelo. Cluster di questo genere erano in genere cluster di computer IBM compatibili, implementati utilizzando software Open Source con lo scopo di eseguire task computazionalmente intensivi in genere in ambito tecnico scientifico.</p>
<p>I Beowulf cluster sono caratterizzati da</p>
<ul>
<li>Accesso al sistema possibile solo dal nodo principale, che spesso è l’unico ad essere dotato di tastiera e monitor.</li>
<li>Nodi basati su di una architettura standard (x86, AMD64, PowerPC, etc.), usualmente uguale per tutti i nodi.</li>
<li>Utilizzo di un sistema operativo (in genere GNU/Linux) e software Open Source</li>
</ul>
<h2 id="batch-system">Batch System</h2>
<p>Gli atomi di calcolo (in cui viene istanziato un processo, letti o scritti dati, etc.) in un sistema multiutente (come può essere un cluster) vengono detti <strong>job</strong> (utilizzando una terminologia propria dei sistemi UNIX) e la richiesta di esecuzione di un job da parte di un utente è detta sottomissione di un job.</p>
<p>Per poter distribuire i job degli utenti su un cluster è necessario un software chiamato batch system (o PBS, Portable Batch System). Questi software si occupano di gestire l’ordine di esecuzione dei job e, in un sistema distribuito, di scegliere il nodo su cui verranno eseguiti. Dunque i batch system hanno il compito di accomodare le richieste degli utenti (<em>domanda</em>) e la disponibilità (limitata) di risorse (<em>offerta</em>), operazione nota in questo contesto come <strong>matchmaking</strong>.</p>
<p>Alcuni esempi di batch system sono Condor, Torque/Maui, LSF, SLURM, PBSPro, Oracle Grid Engine, Open Grid Engine.</p>
<p>La maggior parte di questi sistemi organizzano i job in una o più code e per questa ragione sono anche noti come <em>sistemi di code</em>. L’operazione di ordinare i job nella coda di esecuzione è nota come <strong>job scheduling</strong>, o scheduling, ed esistono diversi algoritmi che tentano di ottimizzare il problema dello scheduling rispetto a diversi parametri.</p>
<p>La premessa ovvia al problema dello scheduling è la capacità di monitorare le risorse.</p>
<p>Genericamente i parametri rispetto a cui viene ottimizzato un algoritmo di scheduling sono</p>
<ul>
<li><strong>Throughput</strong>: il numero totale di job che vengono completandoti nell’unità di tempo</li>
<li><p><strong>Latenze</strong> ed in particolare</p></li>
<li><strong>Turnaround Time</strong>: tempo totale tra la sottomissione di un processo ed il suo completamento</li>
<li><p><strong>Response Time</strong>: lasso di tempo che intercorre fra la sottomissione di un job ed una risposta (es. stampa a video sul terminale) da parte del job</p></li>
<li><strong>Fairness</strong>: equità del tempo di calcolo assegnato a job della stessa priorità</li>
<li><p><strong>Waiting Time</strong>: tempo che un job spende inattivo nella propria coda</p></li>
</ul>
<p>In pratica è non è possibile ottimizzare tutti questi parametri contemporaneamente (si consideri ad esempio il throughput e la latenza) ed è necessario realizzare un compromesso. I criteri con cui si realizza quest’ultimo sono caratteristici del particolare algoritmo di scheduling e rispondono a particolari esigenze, ad esempio, nel caso di un sistema in cui la sottomissione di job è un servizio a pagamento, parametri come la fairness ed il waiting time diventano prioritari.</p>
<p>Alcuni esempi algoritmi di scheduling sono Unix Scheduling, FCFS (First Come, First Served), SJR (Shortest Job first), Small Job first / Big Job first, Priority Scheduling, Round Robin, Multilevel Queue, Multilevel Feedback Queue, Fair-share.</p>
<h1 id="principi-di-sicurezza">Principi di sicurezza</h1>
<p>Si considerano preliminarmente alcune definizioni generali</p>
<ul>
<li><strong>Credenziali</strong>: producono prova dell’identità dell’utente, in genere sono uno <em>username</em> ed una <em>password</em> assegnati in combinazione unica</li>
<li><strong>Autenticazione</strong>: verifica dell’identità dell’utente</li>
<li><strong>Autorizzazioni</strong> o permessi, vengono assegnati all’utente assieme alle credenziali e, a seguito della autenticazione, gli permettono o meno di eseguire operazioni su un sistema (istanziare processi, leggere o scrivere dati, etc.)</li>
<li><strong>Confidenzialità</strong>: capacità di inviare un messaggio che solo il destinatario possa comprendere</li>
<li><strong>Integrità</strong>: capacità di stabilire che un messaggio ricevuto sia identico a quello inviato dal mittente, ovvero che non vi siano state alterazioni fra l’invio e la consegna</li>
<li><strong>autenticità e non ripudio</strong>: rispettivamente capacità di stabilire l’identità del mittente ed impossibilità da parte di quest’ultimo di disconoscere il messaggio</li>
</ul>
<h2 id="algoritmi-di-crittografia-simmetrica-e-asimmetrica">Algoritmi di crittografia simmetrica e asimmetrica</h2>
<p>Nei sistemi informatici la confidenzialità è ottenuta crittograficamente. Il messaggio viene cifrato dal mittente utilizzando un algoritmo (noto anche al destinatario) ed una certa <em>chiave</em> mentre il destinatario lo decifra utilizzando una seconda chiave.</p>
<p>Storicamente i primi algoritmi crittografici erano a <strong>chiave simmetrica</strong>, nel senso che una chiave poteva essere ottenuta dall’altra (ad esempio perché erano identiche). Per esempio <strong>AES</strong> (Advanced Encryption Standard, anche conosciuto come <em>Rijndael</em>) è un algoritmo a chiave simmetrica selezionato dal NIST (National Institute of Standards and Technology) sia perché (ad oggi) crittograficamente sicuro sia per le sue performance.</p>
<p>Gli algoritmi a chiave simmetrica pongono intrinsecamente dei rischi di sicurezza, indipendentemente dalla bontà degli algoritmi. Infatti perché il destinatario possa ricostruire il messaggio è <em>necessario che conosca la chiave</em>. Il mittente è pertanto costretto a comunicargliela e per fare ciò è necessario un canale di trasmissione sicuro, che però potrebbe non esistere (ovviamente non ha senso crittografare una chiave simmetrica con una chiave simmetrica perché si riporrebbe il problema).</p>
<p>Inoltre gli algoritmi a chiave simmetrica soffrono di un ulteriore problema. Infatti il mittente dovrà condividere una chiave differente con ogni destinatario (posto che sia interessato a trasmettere in maniera segreta con ciascun destinatario rispetto ad ogni altro destinatario). Questo comporta che il numero di chiavi (che devono essere trasmesse e conservate in maniera sicura) cresca in una rete di utenti come il quadrato del numero di questi ultimi.</p>
<p>Questo genere di problemi è risolto tramite l’uso di <strong>chiavi asimmetriche</strong>. Negli algoritmi asimmetrici esistono due chiavi, una detta <strong>pubblica</strong> e l’altra <strong>privata</strong>, e la chiave privata è in grado di decifrare un messaggio cifrato tramite la chiave pubblica. Tramite l’uso di algoritmi asimmetrici il destinatario può inviare (o rendere appunto pubblica) una copia della propria chiave pubblica, ma conservare la propria chiave privata, e per il mittente sarà sufficiente cifrare il messaggio utilizzando la chiave pubblica del destinatario. Una volta consegnato il messaggio il destinatario potrà decifrarlo utilizzando la propria chiave privata.</p>
<p>In generale, essendo questi algoritmi computazionalmente costosi, nel caso di messaggi molto grandi si adotta usualmente la strategia di cifrare questi ultimi usando una chiave simmetrica e poi di condividere la chiave simmetrica cifrandola con un algoritmo asimmetrico.</p>
<p>Uno dei primi algoritmi a chiave asimmetrica ad essere scoperti (1978) ed oggi maggiormente adottati è <strong>RSA</strong> (da nomi dei suoi inventori Ronald Rivest, Adi Shamir e Leonard Adleman). In questo caso le chiavi consistono in genere di una coppia di file ed una <em>passphrase</em>, nota solo al proprietario della chiave privata.</p>
<p>L’algoritmo RSA ha inoltre la seguente utile proprietà. Si è già visto che un messaggio cifrato usando la chiave pubblica può essere decifrato utilizzando la chiave privata, tuttavia è vero anche il contrario: ovvero un messaggio cifrato utilizzando la chiave privata può essere decifrato usando la chiave pubblica.</p>
<h2 id="firma-digitale">Firma digitale</h2>
<p>Per <strong>hash</strong> o <strong>one-way hash function</strong> si intende una funzione <span class="math inline"><em>H</em></span> (in pratica un algoritmo) che riceve una stringa di lunghezza qualsiasi <span class="math inline"><em>M</em></span> e restituisce una stringa di lunghezza fissata <span class="math inline"><em>h</em></span> tale che</p>
<ol style="list-style-type: decimal">
<li>dato <span class="math inline"><em>M</em></span>, sia semplice (economico) calcolare <span class="math inline"><em>h</em> = <em>H</em>(<em>M</em>)</span></li>
<li>dato <span class="math inline"><em>h</em></span>, sia difficile (costoso) calcolare gli elementi di <span class="math inline"><em>H</em><sup>−1</sup>(<em>h</em>)</span></li>
<li>dato <span class="math inline"><em>M</em></span>, sia difficile (costoso) calcolare <span class="math inline"><em>M</em>′</span> tale che <span class="math inline"><em>H</em>(<em>M</em>)=<em>H</em>(<em>M</em>′)</span> (ci si riferisce a questa eventualità col termine <strong>collisione</strong>)</li>
</ol>
<p>Si osserva che, a differenza degli algoritmi crittografici, gli algoritmi di hashing non sono per definizione invertibili (non esiste una corrispondenza univoca fra <span class="math inline"><em>M</em></span> e <span class="math inline"><em>h</em></span>). La conseguenza di questo fatto è che esistono certamente collisioni.</p>
<p>Può essere più economico, o interessante per altre ragioni, calcolare le funzioni di hash per due stringe e confrontare i risultati che confrontare direttamente le stringe di partenza. In questo caso il risultato delle funzioni di hash si chiama <strong>checksum</strong> e si preferiscono funzioni di hash che abbiano la ulteriore proprietà che la probabilità di collisione sia <em>piccola</em> per stringhe di partenza <em>simili</em>.</p>
<p>L’integrità, l’autenticità ed il non ripudio possono essere ottenuti sfruttando le funzioni di hash e l’algoritmo RSA. In questo caso il mittente che vuole apporre la propria <strong>firma digitale</strong> su un messaggio (eventualmente in cifrato) calcola lo hash del messaggio, lo cifra con la sua chiave privata ed allega il risultato al messaggio. In questo modo il destinatario potrà calcolare lo hash del messaggio, decifrare tramite la chiave pubblica quello in allegato ed effettuare un confronto.</p>
<p>Se i due hash coincidono il destinatario potrà dedurre che</p>
<ol style="list-style-type: decimal">
<li>Il messaggio ricevuto coincide (a meno di una collisione, eventualità con probabilità trascurabili) con quello su cui il mittente ha apportato la firma (integrità)</li>
<li>Il mittente può essere solo il proprietario della chiave privata (autenticità) e quest’ultimo non può negare di aver firmato il messaggio (non ripudio)</li>
</ol>
<h2 id="certificati-personali-secondo-lo-standard-x.509">Certificati personali secondo lo standard X.509</h2>
<p>Gli algoritmi a chiave asimmetrica e la firma digitale costituiscono una soluzione a certi problemi di sicurezza se sono vere alcune premesse</p>
<ol style="list-style-type: decimal">
<li>Le chiavi private degli utenti non sono compromesse</li>
<li>Gli utenti sono in grado di associare con sicurezza l’identità di altri utenti alle rispettive chiavi pubbliche (che in qualche modo devono essere state distribuite in precedenza)</li>
</ol>
<p>Esistono due modelli per garantire la seconda di queste premesse</p>
<ol style="list-style-type: decimal">
<li><strong>X.509</strong>: controllo centrale da parte di un terzo individuo (<em>hierarchical organization</em>)</li>
<li><strong>PGP</strong>: sistema distribuito con relazioni fra pari (<em>web of trust</em>)</li>
</ol>
<p>Nel secondo caso si sfrutta l’assunto che se si conosce l’identità di un utente e quest’ultimo <em>garantisce</em> sull’identità di un terzo utente, allora si può considerare (ragionevolmente) sicura l’identità di questo terzo utente, anche nel caso non fossimo in grado di stabilirla direttamente.</p>
<p>Questo ragionamento si può applicare più volte ed è eventualmente possibile stabilire in questo modo una o più catene di relazioni di fiducia fra mittente e destinatario.</p>
<p>In pratica in una <em>web of trust</em> un utente che sia sicuro della identità associata ad una chiave pubblica può firmarla e queste chiavi pubbliche firmate sono raccolte in database liberamente accessibili online. Software come <strong>GPG</strong> (GNU Privacy Guard), oltre a permettere di cifrare, decifrare e firmare messaggi, ricostruiscono automaticamente queste relazioni di fiducia in base alle chiavi pubbliche fidate nel proprio <em>portachiavi</em>.</p>
<p>X.509 è uno standard per PKI (Public Key Infrastructure), che permette di realizzare relazioni di fiducia tra utenti tramite un controllo centrale.</p>
<p>Esistono due concetti fondamentali nello standard X.509</p>
<ol style="list-style-type: decimal">
<li><strong>Certification Authority</strong> o CA</li>
<li><strong>Certificati digitali</strong></li>
</ol>
<p>La certification authority è una terza parte la cui identità è per ipotesi fidata (<em>trust anchor</em>) che può rilasciare certificati digitali per utenti, software o calcolatori. Si occupa di verificare l’identità dei richiedenti (tramite le RA, Registration Authorities) e pubblica periodicamente un elenco dei certificati compromessi che sono ancora in periodo di validità nelle CRL (Certificate Revocation Lists).</p>
<p>I certificati digitali rappresentano una estensione del concetto di chiave pubblica e contengono almeno i seguenti campi</p>
<ol style="list-style-type: decimal">
<li>la chiave pubblica del proprietario del certificato</li>
<li>l’identità del proprietario (es. dati anagrafici)</li>
<li>alcune informazioni sulla CA</li>
<li>periodo di validità del certificato</li>
<li>firma digitale della CA</li>
</ol>
<p>Il mittente in questo modo può esaminare il certificato (dopo averne ricevuto copia) ed essere sicuro della corrispondenza fra l’identità del destinatario e la sua chiave pubblica.</p>
<p>Per poter applicare lo schema X.509 è tuttavia necessario che un utente possieda la chiave pubblica della CA (che deve essere stata ottenuta tramite un canale sicuro perché è per ipotesi fidata). Queste chiavi vengono solitamente distribuite sotto forma di certificati, detti <em>root certificate</em>, in modo da contenere informazioni addizionali come ad esempio il periodo di validità della chiave. Inoltre i root certificate sono <strong>self signed</strong>, ovvero firmati dallo stessa CA, ed è pertanto possibile stabilirne l’integrità (l’autenticità è data per ipotesi).</p>
<h1 id="grid-computing">Grid Computing</h1>
<h2 id="principi-di-calcolo-a-grid">Principi di calcolo a Grid</h2>
<p>Una <strong>Grid computazionale</strong>, o semplicemente una Grid, è una infrastruttura hardware e software che garantisca un accesso affidabile, coerente, capillare ed economico a risorse computazionali ad alte prestazioni.</p>
<p>Dal punto di vista delle istituzioni che forniscono queste risorse il suo scopo è permettere una condivisione flessibile, sicura e coordinata di queste ultime.</p>
<p>Inoltre, dato l’interesse nella condivisione dinamica di risorse fra diverse organizzazioni, le tecnologie Grid non possono rimpiazzare le preesistenti tecnologie per il calcolo distribuito, ma devono piuttosto coesistere ed essere complementari a queste ultime.</p>
<p>Gli utenti di un sistema Grid operano generalmente all’interno di organizzazioni virtuali, a cui sono garantiti certi permessi e risorse.</p>
<p>Ci sono tre proprietà fondamentali che caratterizzano una Grid rispetto ad altri sistemi per il calcolo distribuito</p>
<ol style="list-style-type: decimal">
<li>Coordinazione su <em>larga scala</em> di risorse geograficamente distribuite ed appartenenti a diversi domini amministrativi</li>
<li>Protocolli ed interfacce standard, aperte e polivalenti, tali da provvedere ad una ampia gamma di servizi</li>
<li>Capacità di fornire vari tipi di qualità del servizio (QoS, Quality of Service), ovvero di coordinare le risorse in modo da fornire un servizio calibrato sulle richieste degli utenti.</li>
</ol>
<p>Inoltre una Grid presuppone l’assenza di</p>
<ol style="list-style-type: decimal">
<li><strong>Central control</strong>: una istituzione/nodo centrale a cui facciano riferimento tutti gli altri.</li>
<li><strong>Omniscience</strong>: la conoscenza da parte di ogni istituzione/nodo dello stato di tutti gli altri.</li>
<li><strong>Existing Trust Relationship</strong>: autenticazione degli individui o delle istituzioni sulla base di relazioni di fiducia preesistenti o comunque esterni alla Grid.</li>
</ol>
<p>Dal punto di vista dell’utente il genere di problemi che una Grid cerca di risolvere è del tipo</p>
<blockquote>
<p>Eseguire il programma X nel sito Y con permessi P, provvedendo accesso ai dati sul sito Z in accordo ai permessi Q</p>
</blockquote>
<p>Riassuntivamente una Grid fornisce un livello di astrazione che rende accessibile un ambiente di calcolo distribuito ad alte performance per gli utenti e che permette la condivisione di risorse per le istituzioni, in maniera trasparente ed immune da tre generi di eterogeneità:</p>
<ol style="list-style-type: decimal">
<li>delle risorse</li>
<li>delle policy</li>
<li>delle applicazioni</li>
</ol>
<p>Si osserva che il calcolo su Grid si può definire calcolo distribuito con le seguenti precisazioni</p>
<ol style="list-style-type: decimal">
<li>Non viene condiviso solo un processo fra i nodi (dunque tempo di CPU e memoria) ma anche dati e software (in breve viene offerto, in accordo ai permessi posseduti dall’utente, l’accesso ad una intera macchina)</li>
<li>L’esecuzione di un singolo job avviene su una singola macchina (o su un singolo cluster di macchine), ovvero i job sono tra loro indipendenti.</li>
</ol>
<p>Un esempio di Grid è <strong>EGI</strong> (European Grid Infrastructure), nata da progetti precedenti come DataGrid e EGEEE (Enabling Grids for E-SciencE).</p>
<h2 id="sottomissione-di-job-ad-una-grid">Sottomissione di job ad una Grid</h2>
<p>Per Grid middleware si intende una serie di componenti software che fungono da intermediari tra l’infrastruttura e le applicazioni utente, rendendo possibile la condivisione di risorse ed infine il calcolo su Grid. Alcuni esempi di Grid middleware sono gLite e EMI, entrambi collegati a EGI.</p>
<p>Le varie componenti di un Grid middleware si possono classificare in</p>
<ol style="list-style-type: decimal">
<li><strong>Servizi di Accesso</strong>: CLI, API, etc.</li>
<li><strong>Servizi di Sicurezza</strong>: autenticazione e autorizzazioni</li>
<li><strong>Servizi di informazione e monitoraggio</strong>: monitoraggio dello stato dei servizi, del carico dei sistemi, etc.</li>
<li><strong>Servizi Dati</strong>: catalogo dei file e delle repliche, catalogo dei metadati, archiviazione fisica dei dati</li>
<li><strong>Servizi di Elaborazione</strong>: gestione dei job, interfacciamento con i siti di calcolo, etc.</li>
</ol>
<p>Considerando l’esempio di EGI è possibile illustrare i diversi componenti di un Grid middleware.</p>
<p>Un utente che vuole sottomettere un job, in questo contesto noto come <em>gridlet</em>, deve preparare un <strong>job description file</strong> ovvero un file che contiene una descrizione del job in un linguaggio noto come <strong>JDL</strong> (Job Description Language).</p>
<p>JDL è un linguaggio flessibile, estensibile e di alto livello, derivato da <strong>ClassAd</strong> (CLASSified Advertisement language), il linguaggio utilizzato dal batch system <em>Condor</em>. Sia JDL che ClassAd contengono una struttura a record composta da un certo numero di attributi separati da un punto e virgola (<code>;</code>).</p>
<p>Un file JDL in genere contiene almeno i seguenti campi</p>
<ol style="list-style-type: decimal">
<li><code>Executable</code> : deve essere uno shell script (in genere bash, csh o tcsh).</li>
<li><code>StdOutput</code> : nome del file che conterrà la l’output del job (i.e. lo standard output)</li>
<li><code>StdError</code> : nome del file che conterrà gli errori del job (i.e. lo standard error)</li>
</ol>
<p>Altri campi importanti sono</p>
<ol style="list-style-type: decimal">
<li><code>Type</code> : può assumere i valori <strong>Job</strong>, che può essere a sua volta normale (default) o parametrico, <strong>DAG</strong> (Directed Acyclic Graph) o <strong>Collection</strong></li>
<li><code>Arguments</code> : contiene gli argomenti da passare allo script che deve essere eseguito</li>
<li><code>Environment</code> : contiene una o più variabili d’ambiente da esportare prima di eseguire lo script (in JDL è possibile costruire un vettore di espressioni con le parentesi graffe <code>{}</code>)</li>
<li><code>InputSandbox</code> : elenco dei file che devono essere inviati insieme al job</li>
<li><code>OutputSandbox</code> : elenco dei file (inclusi lo standard error e output) che devono essere restituiti in caso di esecuzione con successo del job.</li>
<li><code>Requirements</code> : richieste sul working node che eseguirà il job (ad esempio sul sistema operativo, supporto per OpenMP o OpenMPI, etc.)</li>
</ol>
<p>Si osserva che con una singola richiesta è possibile istanziare più job in una volta, infatti</p>
<ul>
<li>un job parametrico è un job in cui uno o più argomenti variano in un intervallo</li>
<li>un DAG è un insieme di job con relazioni di dipendenza reciproca che possono essere descritte da un grafo diretto aciclico (e per il quale esiste una specifica sintassi)</li>
<li>una collezione è un insieme di job indipendenti</li>
</ul>
<p>Si osserva che in questo modo si riduce il tempo di sottomissione (singola autenticazione/autorizzazione, etc.).</p>
<p>Considerato lo script di esempio</p>
<pre><code>#!/bin/sh
# test.sh
echo $*</code></pre>
<p>un semplice job description file può essere (i commenti su una linea usano <code>#</code> quelli su più linee devono essere incapsulati in <code>/* */</code>)</p>
<pre><code># test.jdl
Executable = "test.sh";
Arguments = "Hello world!";
StdOutput = "std.out";
StdError = "std.err";
InputSandbox = {"test.sh"};
OutputSandbox = {"std.out", "std.err"};</code></pre>
<p>Il job description file viene quindi inviato al <strong>WMS</strong> (Workload Management System), che (fra gli altri) ha l’incarico di assegnare l’esecuzione del job ad un particolare sito di calcolo (CE, Computing Element, che in generale può essere una macchina o un cluster) tenendo conto delle preferenze espresse nel job description file (matchmaking). A questo punto il job si trova in una <strong>coda globale</strong>, in attesa di essere assegnato. Successivamente il WMS richiede informazioni allo <strong>Information Index</strong> o <strong>Information System</strong>, che contiene un database dei CE attualmente disponibili, del loro carico di lavoro ed eventualmente delle loro policy. Si osserva che a questo scopo i CE comunicano direttamente con lo information index. Tramite queste informazioni uno dei componenti del WMS detto <strong>Resource Broker</strong> computa il CE più opportuno su cui eseguire il job. Il WMS può quindi inoltrare il job su una <strong>coda locale</strong> attraverso un suo componente che il cui compito è interfacciarsi con il batch system locale del CE (CREAM, Computing Resource Execution and Management, per gLite e EMI-ES, EMI Execution Service, per EMI). Fra i batch system supportati figurano PBS(Torque/MAUI), LSF, SGE.</p>
<p>Ogni passaggio del ciclo di vita di un job è registrato da un servizio chiamato <strong>Logging and Bookkeeping</strong> (LB), con cui sono in comunicazione sia il WMS che il CE. Questo è utile ad esempio per conoscere lo stato di un job che è stato sottomesso, infatti gli utenti possono tracciare lo stato del proprio job conoscendone lo ID (che viene comunicato durante la sottomissione). Dopo essere stato eseguito successo da un <strong>Worker Node</strong> l’output del job viene inoltrato automaticamente (tramite il CE) al WMS , da cui l’utente può ottenere una copia (in questo schema l’utente non si interfaccia mai direttamente col CE, tuttavia non è l’unica implementazione possibile).</p>
<p>Tra i comandi a disposizione di un utente vi sono</p>
<table>
<thead>
<tr class="header">
<th align="left"><strong>Description</strong></th>
<th align="left"><strong>Command</strong></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left">Submitting a job</td>
<td align="left"><code>glite-wms-job-submit</code></td>
</tr>
<tr class="even">
<td align="left">Checking job status</td>
<td align="left"><code>glite-wms-job-status</code></td>
</tr>
<tr class="odd">
<td align="left">Retrieving job output</td>
<td align="left"><code>glite-wms-job-output</code></td>
</tr>
<tr class="even">
<td align="left">Checking job history</td>
<td align="left"><code>glite-wms-job-logging-info</code></td>
</tr>
<tr class="odd">
<td align="left">Listing compatible resources</td>
<td align="left"><code>glite-wms-job-list-match</code></td>
</tr>
<tr class="even">
<td align="left">Delegate a proxy</td>
<td align="left"><code>glite-wms-job-delegate-proxy</code></td>
</tr>
</tbody>
</table>
<h2 id="gestione-della-sicurezza-in-grid">Gestione della sicurezza in Grid</h2>
<p>In genere in una Grid viene utilizzato (ed ampliato) lo standard X.509. Ad esempio in EGI le certification authority riconosciute sono diverse ed hanno in genere base nazionale, tuttavia esiste un progetto per la coordinazione delle CA europee chiamato EUGridPMA (quest’ultimo in realtà include diverse CA extra-europee, oltre a collaborare con analoghe organizzazioni in Asia e negli Stati Uniti).</p>
<p>Sempre in EGI i root certificate sono distribuiti tramite <em>pacchetti</em> per diversi sistemi operativi e disponibili in repository pubblici (dopo aver aggiunto il repository è possibile installare tutti i certificati tramite il meta-pacchetto <code>lcg-CA</code>).</p>
<p>Uno degli standard di sicurezza adottato su Grid è GSI (Grid Security Infrastructure) basato sullo standard PKI X.509. In questo standard ogni transazione (scambio di dati, invio di istruzioni, etc.) è <strong>mutualmente autenticata</strong>.</p>
<p>Infatti tramite lo standard di sicurezza X.509 è possibile risolvere (oltre ai problemi di confidenzialità, integrità e non ripudio) il problema della autenticazione. Il meccanismo è il seguente.</p>
<p>All’inizio di una transazione tra due utenti A e B (ciascuno dei due può essere un individuo, un software o una macchina), dopo aver stabilito una connessione</p>
<ol style="list-style-type: decimal">
<li>A invia a B una copia del proprio certificato.</li>
<li>B ne verifica la validità tramite la firma della CA (che può verificare a sua volta tramite i root certificates).</li>
<li>Se la verifica del certificato di A è andato a buon termine, B invia un messaggio casuale (<em>challenge string</em>) che contiene un <em>timestamp</em>, ovvero una indicazione che permette di datare univocamente la transazione.</li>
<li>A firma la challenge string ed invia la firma a B.</li>
<li>B verifica la firma e autentica A</li>
</ol>
<p>Perché vi sia mutua autenticazione si ripete la procedura a ruoli invertiti. Si osserva che il solo certificato non autentica A, ma garantisce soltanto la corrispondenza fra l’identità di A ed una chiave pubblica. Invece nella procedura descritta (anche nota come CHAP, Challenge-Handshake Authentication Protocol) A viene autenticato nella misura in cui si è certi che solo A sia in possesso della chiave privata di A. L’ultima considerazione è cruciale in tutti i sistemi di sicurezza basati su chiavi asimmetriche e deve essere sempre tenuto presente.</p>
<p>Nella effettiva implementazione della autenticazione nei servizi Grid viene utilizzata una estensione dei certificati X.509 detta <strong>X.509 proxy certificate</strong> o <strong>certificati proxy</strong>. Questi certificati sono contraddistinti dalle seguenti caratteristiche</p>
<ol style="list-style-type: decimal">
<li>Hanno durata piuttosto breve, dell’ordine di alcune ore (usualmente 12) contro i certificati personali che hanno in genere durata annuale</li>
<li>Contengono al loro interno una coppia di chiavi, pubblica e privata</li>
</ol>
<p>Questa estensione ha la seguente motivazione. Nel contesto di una Grid è spesso necessario che un servizio o l’istanza di un software possano agire per conto dell’utente (ad esempio un job può aver bisogno di recuperare una copia di un file e dunque di dover contattare un server ed autenticarsi). Deve pertanto esistere un meccanismo in grado di trasferire la propria capacità di autenticazione, questo meccanismo è noto come <strong>delegazione</strong>.</p>
<p>Una soluzione ingenua potrebbe essere quella di rilasciare insieme al proprio certificato una copia della propria chiave privata. Tuttavia per quanto già osservato una soluzione di questo genere comporterebbe gravi problemi di sicurezza.</p>
<p>Quando si crea un certificato proxy vengono create una coppia di chiavi ed incluse nel certificato, tuttavia la propria chiave privata personale <strong>non</strong> viene allegata. In questo modo la propria identità è stata delegata. Infatti un individuo o un servizio in possesso un certificato proxy potrà non solo instaurare una relazione di fiducia con altri utenti (essendo in possesso di un certificato valido), ma anche autenticarsi grazie alla propria chiave privata.</p>
<p>Inoltre un proxy può delegare a sua volta la propria identità prolungando la catena della fiducia.</p>
<p>Chiaramente in termini di sicurezza un proxy è un compromesso. Infatti la delegazione implica che esista nel sistema una coppia di chiavi (non cifrate). Pertanto, tramite la chiave privata di un proxy, è possibile impersonare l’identità (delegata) dell’utente che in origine ha creato il proxy. Tuttavia la delegazione è solo temporanea ed ha il grande vantaggio che la chiave privata dell’utente rimane sempre segreta.</p>
<p>Lo standard GSI prevede ulteriori estensioni a X.509 con lo scopo di semplificare la gestione delle autorizzazioni. Infatti il problema delle autorizzazioni è complesso e consiste nell’accomodare i permessi garantiti da due diverse entità</p>
<ol style="list-style-type: decimal">
<li>Virtual Organization (VO)</li>
<li>Resource Provider (RP),</li>
</ol>
<p>Lo sviluppo dei <strong>VOMS</strong> (Virtual Organization Membership Service) nei sistemi Grid è stato una risposta all’esigenza di centralizzare la gestione delle autorizzazioni nelle organizzazioni virtuali. A questo scopo i certificati proxy sono stati estesi al fine di poter (opzionalmente) contenere informazioni associate ai permessi entro l’organizzazione virtuale di appartenenza. Queste informazioni sono</p>
<ol style="list-style-type: decimal">
<li>Organizzazione virtuale di appartenenza</li>
<li>Una lista dei gruppi di appartenenza. Infatti le organizzazioni virtuali hanno una struttura ad albero (simile ad un filesystem UNIX) i cui nodi sono le organizzazioni e di cui la VO rappresenta la radice (ogni utente della VO deve appartenere ad almeno un gruppo e può appartenere a più gruppi)</li>
<li>Ruolo all’interno del gruppo, che può considerarsi come una regolazione fine dei permessi rispetto ai assegnazione ad un gruppo. Si osserva che i ruoli sono relativi al gruppo, nel senso che ruoli con lo stesso identificativo in gruppi diversi hanno diverso significato.</li>
<li>Capacità, ovvero autorizzazioni speciali o temporanee (un utente può ad esempio avere permessi di amministrazione solamente durante i suoi <em>turni</em>)</li>
</ol>
<p>Infine i resource provider sono liberi di computare le autorizzazioni del richiedente sulla base di queste informazioni, delle sue credenziali e delle proprie policy.</p>
<p>I comandi a disposizione dell’utente sono <code>voms-proxy-init</code>, <code>voms-proxy-destroy</code> e <code>voms-proxy-info</code>. L’invocazione di <code>voms-proxy-init</code> comporta le seguenti operazioni. Viene creato un proxy localmente, successivamente viene inoltrato al server VOMS che aggiunge i campi al proxy e lo firma.</p>
<h1 id="cloud-computing-storage">Cloud Computing & Storage</h1>
<p>Le tecnologie di cloud computing hanno avuto negli ultimi anni largo impiego nelle realtà aziendali ed è sempre più probabile che nel futuro diventeranno parte integrante delle infrastrutture per il calcolo scientifico (attualmente già in fase di sperimentazione).</p>
<p>Storicamente Amazon è stata fra le prime aziende a sperimentare queste tecnologie ed a offrire servizi collegati. Ciò nacque dalla esigenza di sfruttare, dunque vendere, le risorse di calcolo in eccesso a propria disposizione, le quali erano state acquistate per affrontare i picchi di domanda sui propri store online in certi periodi dell’anno.</p>
<p>La soluzione ideata fu di mettere a disposizione queste risorse di calcolo ad altre aziende che avessero simili problemi di picchi di carico. Naturalmente una soluzione di questo genere comportò l’ideazione di tecnologie atte a rendere utilmente disponibili queste risorse ed isolare fra loro gli utenti di queste ultime. Oggi, dopo alcuni anni di sviluppo, queste tecnologie vengono complessivamente indicate come <strong>cloud computing</strong>.</p>
<p>Nel caso del cloud computing la <em>tecnologia abilitante</em>, ovvero senza la quale questi sviluppi non sarebbero stati possibili, è stata la <strong>virtualizzazione</strong>.</p>
<h2 id="virtualizzazione">Virtualizzazione</h2>
<p>Informalmente, con virtualizzazione si intende la creazione di una versione virtuale di qualcosa, che può essere ad esempio una piattaforma hardware, un dispositivo o un sistema operativo. Questo comporta la creazione di un livello di astrazione intermedio che riproduce certe funzionalità e nasconde i dettagli di ciò che avviene a più basso livello, interfacciandosi con i livelli di astrazione superiore come farebbe l’oggetto che è stato virtualizzato.</p>
<p>Un esempio di questo genere di tecnologie è la <strong>Java Virtual Machine</strong> (JVM), ovvero un processore virtuale in grado di eseguire un set di istruzioni detto <strong>Java bytecode</strong>. In questo caso se si vuole eseguire codice Java, quest’ultimo deve essere compilato in bytecode ed eseguito su JVM. Questo risolve (in teoria) non solo il problema della portabilità del codice, che in questo modo è indipendente dalla piattaforma, ma anche dello stesso eseguibile, ovvero il java bytecode che può essere eseguito su architetture e sistemi operativi diversi purché sia stata implementata per questi ultimi una JVM.</p>
<p>Nel discorso che segue per virtualizzazione si intenderà <em>virtualizzazione dell’intera piattaforma hardware</em>, ovvero dove generalmente il livello di astrazione creato si frappone fra l’hardware fisico ed il sistema operativo.</p>
<h3 id="tipi-di-virtualizzazione">Tipi di virtualizzazione</h3>
<p>Si possono distinguere diversi tipi di virtualizzazione ed il primo che è possibile evidenziare è la <strong>emulazione</strong>. Si parla di emulazione quando i sistemi virtuali possiedono una architettura diversa dall’ospite ed usano un differente set di istruzioni. In altri termini nella emulazione l’hardware virtuale viene simulato (a spese di maggiori risorse, dunque <strong>overhead</strong>).</p>
<p>Il caso in cui i sistemi virtualizzati (<em>guest</em>) abbiano la stessa architettura dei sistemi ospite (<em>host</em>) si può distinguere ancora in <strong>virtualizzazione completa</strong> e <strong>paravirtualizzazione</strong>.</p>
<p>Nel caso della virtualizzazione completa il sistema operativo ospite non è a conoscenza di essere eseguito su di una macchina virtuale e vede le stesse interfacce di una macchina fisica e dunque funziona senza alcuna modifica. In questo caso il livello software fra le macchine virtuali (VM) ed la macchina fisica viene detto <strong>hypervisor</strong> ed ha l’onere di tradurre (o inoltrare) le <em>system call</em> delle prime verso quest’ultima.</p>
<p>Nel caso della paravirtualizzazione i sistemi operativi delle VM sono a conoscenza della virtualizzazione dell’hardware sottostante e possono pertanto essere messe in atto delle ottimizzazioni. Queste consistono in modifiche della interfaccia, tramite chiamate speciali dette <strong>hypercall</strong>, permettendo ad esempio di eseguire istanze di codice in un ambiente non virtuale, dunque direttamente sull’hardware.</p>
<p>Gli hypervisor si distinguono a loro volta fra</p>
<ul>
<li>Tipo 1 o <strong>bare metal</strong></li>
<li>Tipo 2 o <strong>hosted</strong></li>
</ul>
<p>Gli hypervisor bare metal vengono eseguiti direttamente sull’hardware e le funzionalità di virtualizzazione si fondono insieme ad un kernel specifico in un SO <em>leggero</em> (dedicato alla virtualizzazione, non general purpose) che include anche tutti i driver per le periferiche ed il sistema di gestione/realizzazione delle macchine virtuali. Sono esempi di hypervisor bare metal: XEN, VMware vSphere, Parallels Server 4, Bare Metal e Hyper-V.</p>
<p>Gli hypervisor hosted invece sono normali applicativi eseguiti all’interno di un sistema operativo, ed in particolare installati ed eseguiti in user space, in grado di fornire funzionalità di virtualizzazione. Un esempio di questi ultimi è Oracle VirtualBox.</p>
<p>Esiste in realtà un terzo genere di hypervisor, in qualche misura ibrido rispetto ai primi due, detto <strong>KVM</strong> (Linux Kernel-based Virtual Machine), il quale è una infrastruttura di virtualizzazione che trasforma il kernel Linux in un hypervisor. In questo caso le funzioni di virtualizzazione vengono offerte da applicativi in user space che tuttavia fanno uso di interfacce esposte da un modulo del kernel Linux. Inoltre KVM può approfittare di alcune estensioni hardware dedicate alla virtualizzazione, in particolare legate alla gestione della memoria, ed in genere supportate dalle ultime generazioni di processori che permettono un migliore sfruttamento delle risorse (riduzione overhead).</p>
<h3 id="vantaggi-della-virtualizzazione">Vantaggi della virtualizzazione</h3>
<p>L’avanzamento tecnologico degli ultimi anni ha prodotto una situazione in cui (generalmente ed in media) gli applicativi non sono più in grado di saturare le risorse hardware disponibili, sia nel caso di personal computing che, in maniera ancora più accentuata, in ambito aziendale.</p>
<p>Infatti si stima che un moderno server venga sfruttato solo al 15-20% e pertanto la virtualizzazione offre, permettendo di ospitare 3 o 4 machine virtuali sullo stesso hardware, il vantaggio di un miglior sfruttamento delle risorse, chiamato in ambito aziendale <strong>consolidamento dei server</strong>, e dunque la <strong>riduzione dei server fisici</strong>. Quest’ultima comporta la riduzione dei consumi energetici (quindi la necessità di impianti di raffreddamento meno potenti), dei <strong>guasti hardware</strong>, dei tempi tecnici per il montaggio ed il cablaggio, del numero di armadi (<em>rack</em>) e pertanto l’abbattimento dello spazio dedicato in sala macchine per questi ultimi ed il loro relativo cablaggio.</p>
<p>Inoltre il software, ed in particolar modo il sistema operativo in esecuzione su una macchina, è in genere strettamente legato all’hardware su cui viene eseguito. Pertanto se, ad esempio per un guasto hardware, si deve migrare una installazione da una macchina ad un’altra, si dovrà spendere del tempo nella configurazione del nuovo hardware. A questo proposito la virtualizzazione offre il vantaggio della <strong>indipendenza hardware</strong>, infatti il sistema operativo guest non si interfaccia con l’hardware fisico ma con un livello di astrazione di quest’ultimo e l’amministratore potrebbe spostare o clonare una macchina virtuale su altre macchine fisiche che eseguano lo stesso ambiente di virtualizzazione senza ulteriore lavoro (se si esclude la configurazione di quest’ultimo).</p>
<p>L’indipendenza dallo hardware in alcuni casi non rappresenta semplicemente una semplificazione della amministrazione straordinaria di sistema ma una necessità. Il tipico esempio è il supporto di vecchie applicazioni (<strong>legacy</strong>), ad esempio sviluppate per DOS, non in grado di supportare hardware più recente. In questi casi gli ambienti di virtualizzazione permettono l’esecuzione anche di sistemi <em>legacy</em> permettendo ai responsabili IT di liberarsi del vecchio hardware non più supportato e più soggetto a guasti.</p>
<p>Un ulteriore vantaggio è la <strong>standardizzazione del runtime</strong>, ovvero mettere appunto ambienti di sviluppo, postazioni di lavoro, server di posta, etc., omogenei in maniera semplicemente riproducibile, e la <strong>creazione di ambienti di test</strong>, ovvero di ambienti isolati che possano essere facilmente creati, distrutti o ripristinati ad uno stato precedente, per testare software.</p>
<h3 id="svantaggi-della-virtualizzazione">Svantaggi della virtualizzazione</h3>
<p>Una delle caratteristiche richieste fin da principio alle tecnologie di virtualizzazione è l’isolamento dei dati e dei processi dei sistemi virtualizzati. In particolare questo aspetto, come si vedrà in seguito, emerge preponderantemente nei casi in cui gli utenti dei sistemi virtualizzati acquistano come servizio l’infrastruttura di virtualizzazione da terzi e pertanto si richiede che sullo stesso hardware coesistano diversi utenti senza collidere.</p>
<p>Tuttavia l’isolamento è realizzato dal software di virtualizzazione ed i <strong>problemi di sicurezza</strong> che derivano da bachi di quest’ultimo sono fra i principali svantaggi di queste tecnologie.</p>
<p>Inoltre l’introduzione di un livello software fra i sistemi virtualizzati e lo hardware ha come inevitabile contropartita una <strong>diminuzione delle performance</strong> (seppure minima, grazie al perfezionamento di queste tecnologie ed al loro elevato grado di maturità). Concretamente questa riduzione delle performance consiste in un overhead di esecuzione praticamente non rilevabile ed in una <strong>riduzione del throughput di I/O</strong> su disco e di rete misurabili (meno importanti nel caso di paravirtualizzazione e trascurabili per quest’ultimo per traffico di rete).</p>
<h2 id="cloud-computing">Cloud Computing</h2>
<p>Le peculiarità delle tecnologie di virtualizzazione hanno introdotto negli ultimi anni una modifica radicale degli approcci al calcolo, con applicazioni al calcolo scientifico.</p>
<p>Storicamente in principio, in ambito aziendale ma anche scientifico, il calcolo era affidato ai <em>mainframe</em>, grandi macchine con differenze architetturali sostanziali rispetto ai server comunemente diffusi oggi, le cui risorse, ovvero tempo di calcolo, venivano allocate in maniera molto critica – sistemi di questo genere continuano ad esistere ad esempio in banche o agenzie governative.</p>
<p>Successivamente, grazie agli sviluppi tecnologici ed in particolare la miniaturizzazione dell’elettronica, si affermò un modello di calcolo basato su hardware in pieno controllo dell’utente (<em>personal computers</em>), successivamente sull’accesso a risorse di calcolo remote (<em>client-server computing</em>) ed in particolare (successivamente) sull’accesso a documenti remoti (<em>Web</em>).</p>
<p>Negli ultimi dieci anni, in particolare grazie alle tecnologie di virtualizzazione, si è sviluppato un nuovo paradigma basato sull’accesso a risorse di calcolo remote con caratteristiche innovative detto <strong>cloud computing</strong>.</p>
<h3 id="traditional-infrastructure-model">Traditional infrastructure model</h3>
<p>Sia in ambito aziendale che scientifico la crescita nel tempo di una istituzione in genere comporta una maggiore richiesta di risorse di calcolo, ad esempio per un aumento della base di utenti.</p>
<p>L’approccio tradizionale a questo problema era di acquistare un surplus di risorse, rispetto alla domanda attuale, per tenere il passo delle delle richieste future. Le previsioni sul tasso di crescita e la frequenza degli aggiornamenti determinavano l’entità di questo surplus. Si osserva che, anche nel caso ideale di una crescita monotona con previsioni affidabili sul tasso di crescita, questa è una soluzione non ottima in quanto per certi lassi di tempo vengono allocate (dunque pagate) risorse che rimangono inutilizzate.</p>
<p>Nei casi reali questo genere di soluzioni presenta ulteriori svantaggi. Infatti in questi ultimi la domanda di risorse, pur potendo avere in media semplice (ad esempio una crescita lineare), è in genere soggetta a fasi di crescita e contrazione, con un tasso non prevedibile. Le conseguenze di queste oscillazioni sono dei <strong>surplus con perdite non accettabili</strong> (spese troppo ingenti rispetto al consumo di risorse) e <strong>periodi di deficit</strong>.</p>
<p>Da questa discussione emerge che i problemi di questo approccio sono la lentezza degli interventi di aggiornamento delle infrastrutture e la loro irreversibilità, nel senso che una volta acquistate non è possibile (o non è conveniente) cederle o smantellarle e rappresentano un costo fisso.</p>
<p>Il <strong>cloud computing</strong> è un insieme di tecnologie che permette un approccio al problema delle risorse radicalmente differente, rendendo possibile ad esempio approntare una infrastruttura di calcolo in tempi dell’ordine di alcuni minuti, contro le diverse settimane necessarie nel caso di IT tradizionale.</p>
<h3 id="definizione-di-cloud-computing">Definizione di cloud computing</h3>
<p>In letteratura la definizione di riferimento per le tecnologie di cloud computing è quella data dal NIST, che in sintesi definisce queste ultime come</p>
<blockquote>
<p><strong>fornitura</strong> di tecnologia di <strong>informazione e comunicazione</strong> (ICT) come <strong>servizio</strong></p>
</blockquote>
<p>Si osserva che concettualmente il termine di maggior peso in questa definizione è <em>servizio</em>, il quale racchiude il contenuto innovativo di queste tecnologie (e dei paradigmi che le rendono possibili).</p>
<p>La definizione del NIST inoltre prevede alcuni punti</p>
<ul>
<li><strong>On demand self service:</strong> l’utente del servizio deve essere in grado di ottenere in maniera semplice, trasparente ed automatica risorse di calcolo, come ad esempio CPU time o dischi, alla bisogna, senza la necessità di una interazione diretta con gli amministratori dei service provider o di un intervento umano.</li>
<li><strong>Broad network access:</strong> il servizio deve essere distribuito ed accessibile tramite la rete</li>
<li><strong>Resource pooling:</strong> le risorse di calcolo, fisiche o virtuali, disponibili al service provider devono essere distribuite e riassegnate dinamicamente agli utenti in base alla domanda senza che questi ultimi collidano, ovvero realizzando una condizione di <strong>isolamento</strong> dei dati e dei processi di questi ultimi in un ambiente fortemente <strong>multi-tenant</strong>.</li>
<li><strong>Rapid elasticity:</strong> il servizio deve essere non solo in grado di fornire risorse di calcolo <em>elasticamente</em>, ovvero in base al carico, ma specialmente in maniera <strong>rapida</strong>, ovvero adattandosi a quest’ultimo in tempi brevi ed idealmente tenendo il passo della domanda in tempo reale.</li>
<li><strong>Measured service:</strong> i service provider devono essere in grado di misurare l’erogazione del servizio, utilizzando metriche di un livello di astrazione adeguato al genere di servizio, in modo da poter sia addebitare eventuali costi di servizio che, più in generale, ottimizzare le risorse fra gli utenti, ad esempio in base alle priorità assegnate alle organizzazioni a cui appartengono.</li>
</ul>
<p>Una analogia utile a cogliere alcuni aspetti del cloud computing è quella con il noleggio auto:</p>
<ul>
<li>l’utente effettua una prenotazione telefonica o online senza la necessità di un intervento umano (<em>self service</em>) e accendendo un contratto temporaneo relativo alla prestazione particolare (<em>on demand</em>)</li>
<li>il service provider (agenzia di autonoleggio) possiede una rete di distribuzione geograficamente distribuita (<em>broad network access</em>)</li>
<li>le risorse (il parco vetture) viene riorganizzato per garantire il servizio in maniera trasparente all’utente (<em>resource pooling</em>)</li>
<li>i dettagli del noleggio sono stabiliti in base alla domanda e possono essere semplicemente modificati (<em>rapid elasticity</em>)</li>
<li>l’addebito agli utenti viene effettuato in base al consumo (<em>measured service</em>)</li>
</ul>
<!-- L'ultimo punto mostra una analogia con il cloud computing che mette in luce l'inadeguatezza delle infrastrutture IT tradizionali: data una richiesta di maggiori risorse, in questo caso autovetture (server nel caso IT), per l'utente sarebbe necessario acquistarne al loro inter costo dell'intero parco vetture! -->
<h3 id="service-models">Service models</h3>
<p>Il paradigma reso possibile dalle tecnologie di cloud computing presenta delle analogie con altri sistemi di condivisione di risorse di calcolo geograficamente distribuite, come ad esempio la GRID, tuttavia <em>nel cloud computing il focus è sul servizio</em> e questa, che è una caratteristica distintiva di queste tecnologie, ne ha sancito il successo in ambito aziendale.</p>
<p>Infatti nel caso del grid computing la risorsa messa a disposizione dalla infrastruttura è essenzialmente la capacità di eseguire un applicativo, ovvero di sottomettere un job ad un <strong>batch system</strong>. Quest’ultima è una differenza sostanziale rispetto al cloud computing propriamente detto in cui il panorama dei servizi offerti è molto più ricco e variegato, comportando un profondo divario nella implementazione di queste due tecnologie oltre che nell’approccio al problema.</p>
<p>Inoltre il grid computing si è affermato solamente all’interno della comunità scientifica mentre il cloud computing ha suscitato grande interesse nelle realtà aziendali ed è oggi una tecnologia matura ampliamente adottata in questi contesti, con alcune sperimentazioni in ambito scientifico.</p>
<p>Le tecnologie di cloud computing vengono in genere classificate in base alla tipologia di servizi che vengono erogati e si distinguono, in prima istanza, in tre livelli</p>
<ul>
<li>Infrastructure as a Service (<strong>IaaS</strong>)</li>
<li>Platform as a Service (<strong>PaaS</strong>)</li>
<li>Software as a Service (<strong>SaaS</strong>)</li>
</ul>
<p>e successivamente il concetto di <em>Something as a Service</em> è stato esteso ad altri sottolivelli e servizi specifici.</p>
<h3 id="infrastructure-as-a-service">Infrastructure as a Service</h3>
<p>Nel caso di IaaS il service provider mette a disposizione essenzialmente un ambiente di virtualizzazione e fornisce un certo numero di macchine virtuali, con certe caratteristiche, in base alla domanda dell’utenza. Pertanto in questo livello di servizio tutto ciò che arriva fino al livello del sistema operativo è di competenza del service provider, mentre ciò che viene installato sulla macchina (middleware, software, etc.) diventa responsabilità dell’utente.</p>
<p>Semplificando, la differenza rispetto alla virtualizzazione su hardware in proprio controllo è che è possibile ottenere in pochi passaggi e su richiesta una macchina virtuale, con CPU, memoria e dischi richiesti, con un sistema operativo scelto senza dover conoscere i dettagli, o dover spendere energie nell’implementazione, della infrastruttura sottostante.</p>
<p>In questo caso l’utente può configurare il servizio assemblando virtualmente macchine, dischi, componenti di rete, etc, in maniera automatizzata senza interagire direttamente con gli amministratori del datacenter in cui è fisicamente ospitato lo hardware (ad esempio tramite una interfaccia Web). Tuttavia questo da solo non sarebbe sufficiente a definire questo genere di servizi cloud computing, infatti ciò che permette di definire quest’ultimo cloud computing è la <strong>flessibilità</strong> del servizio, in accordo al concetto più generale di <em>rapid elasticity</em> (che diventa <strong>dinamicità</strong> o <strong>scalabilità dinamica</strong> del caso SaaS o PaaS).</p>
<p>Ad esempio un ipotetico servizio in cui sia possibile noleggiare una macchina virtuale con certe caratteristiche accendendo un contratto specifico per quella soluzione (<em>managed hosting</em>) non potrebbe essere definito cloud computing: nel caso di IaaS è importante che l’utente sia in grado di modificare le caratteristiche del servizio, ovvero l’infrastruttura e dunque CPU, dischi, etc., dinamicamente.</p>
<p>Questi servizi sono caratterizzati da:</p>
<ul>
<li>Ambienti multitenant virtualizzati e sistemi critici per l’isolamento dei dati e dei processi degli utenti</li>
<li>Addebito in genere stabilito in base al wall time, non in base all’uso</li>
<li>Nelle implementazioni reali, possibilità di accoppiare servizi per l’installazione e la manutenzione dei sistemi operativi o del runtime</li>
<li>Accesso con diritti di amministrazione da parte dell’utente</li>
</ul>
<p>Lo svantaggio peculiare della IaaS consiste nella lentezza e nella complessità nella creazione o modifica di macchine virtuali. In risposta a queste difficoltà molti utenti hanno preferito sistemi più evoluti, nella direzione di PaaS e SaaS, in cui i sistemi scalino dinamicamente, in maniera più automatica e trasparente all’utente, e IaaS è rimasto un servizio riservato ad utenti con esigenze piuttosto specifiche.</p>
<h3 id="platform-as-a-service">Platform as a Service</h3>
<p>Nel caso Platform as a Service quello che fornisce il service provider è un sistema dove il runtime è già disponibile, ovvero dove l’applicazione oggetto del servizio è pronta per essere usata dallo sviluppatore, che in questo contesto è l’utente del servizio. Ad esempio prima di poter sviluppare codice in C è necessario istallare un compilatore, un debugger ed in genere delle librerie, nel caso di PaaS allo sviluppatore viene fornito un ambiente pronto per la compilazione e l’esecuzione del codice, senza che quest’ultimo sia a conoscenza dei dettagli dell’infrastruttura che rende questo possibile o dell’onere di doverla preparare.</p>
<p>Nel caso PaaS il service provider fornisce all’utente tutti gli strumenti per lo sviluppo remoto delle sue applicazioni in maniera semplice (ad esempio tramite l’uso di interfacce Web) e la possibilità di gestire in maniera semplice l’intero ciclo di vita di queste ultime.</p>
<p>Sinteticamente Platform as a Service è un metodo per l’erogazione di risorse di calcolo attraverso una piattaforma, ovvero tramite una infrastruttura di componenti hardware e software disponibile all’uso e di cui non è necessario conoscere i meccanismi interni. Tutto ciò permette in questo modo di abbattere i tempi ed i costi per lo sviluppo ed il collaudo di applicazioni ed ha segnato il successo di questo approccio. Tuttavia questo da solo non sarebbe sufficiente per parlare di questi servizi come cloud computing, infatti la caratteristica principale di questi servizi è di scalare dinamicamente in base alle richieste degli applicativi sottomessi.</p>
<p>Questo tipo di servizi è caratterizzato da:</p>
<ul>
<li>Ambienti multitenant</li>
<li>Scalabilità dei sistemi</li>
</ul>
<p>Il principale svantaggio per l’utenza nella sottoscrizione a questi servizi è la dipendenza degli applicativi dalla piattaforma particolare e dunque la difficoltà, o addirittura l’impossibilità, di migrare verso un’altro service provider in un secondo momento.</p>
<p>Come già osservato i service provider di IaaS hanno gradualmente inglobato servizi di PaaS ed oggi è molto difficile trovare un service provider che faccia esclusivamente PaaS.</p>
<h3 id="software-as-a-service">Software as a Service</h3>
<p>L’ultimo livello nella scala dei servizi offerti dal service provider è il caso <strong>Software as a Service</strong>, o <strong>cloud application</strong>. In questo caso l’utente del servizio è effettivamente l’utente finale ed a quest’ultimo viene fornito direttamente l’applicativo. Alcuni esempi noti sono <strong>Gmail</strong> e <strong>Google Documents</strong>.</p>
<p>Questi applicativi sono probabilmente la forma più popolare di cloud computing e sono in genere di utilizzo molto immediato, infatti sono in genere accessibili direttamente tramite un browser web e rimuovono la necessità di installazione e configurazione del software su computer individuali. Comportano inoltre notevoli semplificazioni anche per i fornitori del servizio, specialmente nell’erogazione del supporto dal momento che tutta l’infrastruttura (applicativi, rutime, sistema operativo e hardware) sono loro direttamente accessibili.</p>
<p>Sinteticamente si può dire che SaaS è un metodo per la distribuzione di applicativi che fornisce un accesso remoto alle funzionalità di questi ultimi, usualmente tramite interfacce Web, a diversi utenti forniti di licenza. Questi servizi sono in genere caratterizzati da</p>
<ul>
<li>Ambienti multitenant e sistemi per l’isolamento dei dati degli utenti</li>
<li>Universalmente accessibili, ovvero entro certi limiti indipendenti dal software o hardware particolare dell’utenza</li>
<li>Addebiti stabiliti in base all’uso</li>
<li>Grande scalabilità dei sistemi per l’erogazione del servizio (intrinseca nella gestione del servizio e completamente delegata al fornitore)</li>
<li>Sistemi di gestione delle licenze quindi, termini più astratti, gestione critica dei permessi</li>
<li>Isolamento dei dati degli utenti</li>
</ul>
<p>I principali problemi per l’utenza di questi servizi sono legati all’accesso, la persistenza ed al possesso ai dati, con ovvie implicazioni per la privacy degli utenti. Infatti <strong>il servizio ed i dati sono strettamente collegati</strong>, cosa che comporta notevoli conseguenze come ad esempio la possibile perdita dei dati in caso di interruzione del servizio.</p>
<h3 id="alcuni-esempi-di-service-models">Alcuni esempi di service models</h3>
<p>Queste definizioni sono piuttosto astratte e generali, è possibile vedere con alcuni esempi concreti la loro declinazione nel mondo reale.</p>
<h4 id="saas-case-study-salesforce.com-e-google-apps">SaaS case study: Salesforce.com e Google Apps</h4>
<p>Un importante esempio di Software as a Service è <a href="www.salesforce.com">salesforce.com</a> che fornisce software per gestire le relazioni con i clienti per le aziende (<em>business-to-business</em>). In questo caso l’utente, ovvero l’azienda, compone le proprie applicazioni assemblando pacchetti relativi a particolari servizi (modulo gestione clienti, modulo gestione fornitori, gestione del magazzino, etc.).</p>
<p>Nella esperienza comune Google Apps rappresenta un esempio classico di SaaS rivolto agli utenti finali, ovvero i consumatori. Tuttavia questi servizi (oltre a molti altri) sono rivolti anche alle aziende, alle quali viene vengono offerti in una forma simile a quella rivolta ai consumatori ma con la possibilità di personalizzazioni.</p>
<p>Non solo, infatti alcuni di questi servizi vengono offerti gratuitamente ad enti pubblici o di rilievo in cambio della pubblicità derivante dalla adesione ai servizi (ed alla raccolta di dati).</p>
<p>Si osserva comunque che Google in realtà fornisce PaaS, infatti le applicazioni offerte all’utenza condividono le stesse tecnologie, che vengono messe a disposizione degli sviluppatori: questi toolkit incarnano il concetto di PaaS.</p>
<p>Si osserva come questo esempio metta bene in luce le limitazioni dell’approccio PaaS per gli sviluppatori, infatti un ipotetico applicativo che faccia uso dei servizi di geolocalizzazione di Google diventa dipendente da quest’ultimo.</p>
<h4 id="iaas-e-paas-case-study-amazon-aws-e-windows-azure">IaaS e PaaS case study: Amazon AWS e Windows Azure</h4>
<p>Il caso di studio di Amazon AWS è tra i più significativi in quanto la gamma dei servizi offerti è così estesa da poter illustrare tutti gli aspetti di IaaS e PaaS.</p>
<p>Storicamente il primo dei servizi offerti da Amazon Web Services è stato <em>Amazon Simple Storage Service</em> (<strong>S3</strong>), ovvero un sistema per la scrittura e la lettura di dati diverso dal semplice storage remoto (2006). Infatti questo servizio possedeva delle peculiarità che lo rendevano un vero esempio di PaaS. Ad esempio l’accesso ad i dati avveniva programmaticamente: ovvero all’interno di un linguaggio di programmazione tramite delle apposite librerie.</p>
<p>Un’altra caratteristica innovativa di S3 disponibile fin dalla nascita del servizio era quella di richiedere che i dati venissero conservati in data center geograficamente distribuiti.</p>
<p>In un secondo momento è stato varato un servizio per la creazione di macchine virtuali, ovvero <em>Amazon Elastic Computing Cloud</em> (<strong>EC2</strong>), che rappresenta la formulazione classica di IaaS.</p>
<p><strong>Windows Azure</strong> (in precedenza <strong>Microsoft Azure</strong>) è un’altro esempio di di PaaS e IaaS. Quest’ultimo si differenzia rispetto ad AWS nel fatto di essere fortemente orientato allo sviluppo di nuove applicazioni nativamente in cloud.</p>
<h3 id="deployment-and-isolation-models">Deployment and isolation models</h3>
<p>Quanto presentato fin’ora potrebbe indurre a credere che i casi d’uso delle tecnologie di cloud computing riguardino solamente alcune grandi aziende (Amazon, Google, etc.), tuttavia non è questo il caso.</p>
<p>Infatti cloud computing è appunto una tecnologia ed i suoi impieghi possono essere classificati in base a 3 caratteristiche indipendenti: <em>service model</em>, <em>deployment model</em> e <em>isolation model</em>.</p>
<p>I servizi degli esempi precedenti (EC2, Windows Azure,…) sono infrastrutture di cloud che secondo lo standard vengono definite pubbliche, nel senso che chiunque può accedere a questi ultimi dietro compenso economico.</p>
<p>La caso opposto è quella di qualcuno che costruisca una infrastruttura di questo tipo per se stesso e quindi permetta l’accesso a certi utenti particolari. Benché contro-intuitivo, questo genere di soluzioni viene scelto dalla gran parte delle istituzioni sia in ambito accademico che aziendale: ovvero queste istituzioni utilizzano tecnologie di cloud computing su risorse che sono completamente sotto il loro controllo.</p>
<p>In generale si distinguono diversi modelli di erogazione dei servizi:</p>
<ol style="list-style-type: decimal">
<li><strong>Public cloud:</strong> L’utente ha diritto all’accesso di risorse di calcolo remote che sono allocate dinamicamente su richiesta da quest’ultimo, attraverso applicazioni web o API, via internet a seguito della accensione di un contratto. Il service provider addebita all’utente una somma calcolata in base all’utilizzo delle risorse.</li>
<li><strong>Private cloud:</strong> L’utente accede a risorse di calcolo remote che sono fornite da una istituzione di cui fa parte. Spesso l’adozione di queste tecnologie è il primo passaggio prima di una transizione a modelli di Public Cloud. <!-- Le istituzioni che hanno adottato questa soluzione beneficiano delle semplificazioni intrinseche di questi sistemi rispetto alle tradizionali (*batch system*). --></li>
<li><strong>Hybrid cloud:</strong> L’utente ha accesso a risorse sia locali che remote e l’accesso a risorse remote è implementato tramite tecnologie di cloud computing. In genere queste soluzioni sfruttano le tecnologie di cloud computing per funzioni specifiche o in situazioni di carico di lavoro straordinario. Un caso ricorrente, sia in ambito aziendale che accademico, è di fare affidamento a risorse di cloud computing pubbliche in determinati periodi dell’anno ed un esempio in fisica delle alte energie è l’uso di AWS da parte di CMS. In questo modo è stato possibile affrontare richieste di calcolo particolarmente intensive e superiori alle capacità dell’esperimento, acquistando all’asta istanze di calcolo EC2 (<strong>Spot Istances</strong> e <strong>Spot Fleet</strong>), in quanto per Amazon i periodi di inattività rappresentano un costo senza profitto.</li>
<li><strong>Community cloud:</strong> L’utente ha accesso a risorse remote messe a disposizione da una organizzazione di diverse istituzioni le quali collaborativamente condividono una infrastruttura comune di cloud computing. Rispetto al Public cloud le differenze consistono nel minor numero di utenti e nel sistema di addebito del servizio, invece rispetto al Private cloud è possibile partizionare i costi di implementazione e manutenzione del servizio fra le diverse istituzioni.</li>
</ol>
<p>Per isolamento si intendono una serie di aspetti come:</p>
<ul>
<li><strong>Segmentazione delle risorse:</strong> gli utenti devono avere pieno accesso alla quantità di risorse che gli è stata destinata e non altre</li>
<li><strong>Protezione dei dati:</strong> impedire l’accesso o la scrittura di dati da parte di utenti senza permessi</li>
<li><strong>Sicurezza delle applicazioni:</strong> impedire l’esecuzione o la modifica di applicazioni da parte di utenti senza permessi</li>
<li><strong>Auditing:</strong> monitoraggio degli accessi ai propri file o applicativi da parte degli utenti</li>
</ul>
<p>ed i modelli di isolamento sono essenzialmente due:</p>
<ol style="list-style-type: decimal">
<li>Infrastrutture dedicate, con singolo utente o diversi utenti appartenenti alla stessa istituzione</li>
<li>Infrastrutture multitenant, ovvero con diversi tipi di utenti per cui l’isolamento è critico</li>
</ol>
<h3 id="considerazioni">Considerazioni</h3>
<h4 id="interesse-nei-confronti-del-cloud-computing">Interesse nei confronti del Cloud Computing</h4>
<p>L’interesse nei confronti di una nuova tecnologie in genere segue un andamento che si divide in diverse fasi</p>
<ol style="list-style-type: decimal">
<li>Nascita della tecnologia e repentina crescita dell’interesse</li>
<li>Picco di aspettative e massima attenzione nei confronti di quest’ultima</li>
<li>Rapida decrescita e picco negativo dell’interesse</li>
<li>Maturazione della tecnologia con una più graduale crescita dell’interesse</li>
<li>Plateau di produttività caratterizzato da un interesse stabile nel tempo</li>
</ol>
<p>La visibilità del cloud computing ha seguito questo andamento generale ed attualmente ci troviamo nel plateau di produttività.</p>
<h4 id="iaas-cloud-stack-più-usati">IaaS Cloud Stack più usati</h4>
<p>Allo stato attuale esistono diversi software (toolkit) detti <strong>IaaS Cloud Stack</strong> per realizzare una infrastruttura di cloud computing di tipo IaaS. Alcuni di questi sono proprietari, come <strong>WMware</strong> e <strong>Microsoft Hyper-V</strong>, mentre altri sono <em>open source</em>, <strong>OpenStack</strong>, <strong>Apache CloudStack</strong> ed <strong>OpenNebula</strong>, ma in ogni caso si tratta di software che può essere installato e configurato su hardware di proprio controllo per implementare un cloud privato (ma che può eventualmente essere reso successivamente pubblico).</p>
<p>A differenza di quest’ultimo il software impiegato da piattaforme di cloud pubblico, come ad esempio AWS, non può essere impiegato al di fuori della rispettiva piattaforma ed è accessibile solo tramite le IPA pubbliche.</p>
<h4 id="avvantaggiarsi-delle-tecnologie-cloud">Avvantaggiarsi delle tecnologie cloud</h4>
<p>Deve essere chiaro che l’utilizzo delle tecnologie cloud, ad esempio in campo di calcolo scientifico, non garantisce un vantaggio: infatti <strong>è necessario che gli applicativi utilizzati siano sviluppati in modo da approfittare delle potenzialità offerte da queste tecnologie</strong>. In particolare questo software deve avere le seguenti caratteristiche</p>
<ul>
<li><strong>Distribuito:</strong> capacità di eseguire istanze di codice parallelamente su macchine con memoria non condivisa</li>
<li><strong>Immutabile:</strong> caratteristica di non modificare (idealmente) lo stato della macchina durante la propria esecuzione. Questo permette avvantaggiarsi del calcolo distribuito potendo eseguire istanze di porzioni di codice su diverse CPU senza che queste debbano comunicare tra loro, dunque aggirando le latenze di comunicazione tra i processi.</li>
<li><strong>Failover in app:</strong> capacità intrinseca ed automatica di gestione di una eventuale interruzione anomala dei sotto-processi, provvedendo meccanismi per farne partire altri</li>
<li><strong>Scalabilità in app:</strong> capacità di modificare automaticamente e dinamicamente la quantità di risorse utilizzate in base al carico ed alla disponibilità</li>
</ul>
<h4 id="egi-federated-cloud">EGI Federated Cloud</h4>
<p>La <em>EGI federated cloud</em> è una organizzazione che riunisce istituzioni dotate di sistemi di cloud computing privati ed aggrega questi sistemi offrendo alla comunità scientifica, in Europa e nel mondo, servizi di tipo IaaS come unico service provider.</p>
<p>Le idee dietro questo progetto internazionale sono essenzialmente l’adozione di <strong>standard aperti</strong> per le interfacce esposte all’utente, in modo da semplificare sia il <em>resource pooling</em> che l’integrazione con gli applicativi degli utenti, e la <strong>implementazione eterogenea</strong> delle infrastrutture, lasciando libertà agli enti aderenti di utilizzare le tecnologie di loro discrezione dunque semplificando la messa in opera di nuove infrastrutture o l’integrazione di quelle preesistenti.</p>
<p>Un aspetto interessante di questo <em>federated cloud</em> è il <strong>catalogo delle macchine virtuali</strong>, ovvero un elenco pubblico di piattaforme o servizi sviluppati dagli utenti e sottomessi da questi ultimi. Le macchine virtuali in questo catalogo vengono validate dalla federazione ed in questo modo è possibile per gli utenti istanziare servizi sviluppati da altri utenti in un ambiente collaborativo aperto.</p>
<h2 id="cloud-storage">Cloud Storage</h2>
<p>Per <strong>cloud storage</strong> si intende l’utilizzo di tecnologie analoghe al cloud computing (dunque on demand, self service, network access, resource pooling, rapid elasticity, measured service) per l’archiviazione di dati.</p>
<p>A seconda dei casi, queste tecnologie si rendono necessarie</p>
<ul>
<li>in relazione al cloud computing, in quanto il problema del processamento dei dati non può prescindere da quello dell’archiviazione di questi ultimi ed inoltre non è possibile utilizzare soluzioni di archiviazione tradizionali in una infrastruttura di cloud computing</li>
<li>per via di necessità specifiche degli utenti, come ad esempio la necessità di archiviare grandi moli di dati in maniera semplice e trasparente o di doverle condividere.</li>
</ul>
<p>Si individuano tre tipologie di cloud storage nel contesto di servizi di cloud computing di tipo IaaS, escludendo lo storage volatile dello spazio disco della istanza di macchine virtuali (al riavvio di una istanza le modifiche vengono perse)</p>
<ul>
<li><strong>Posix Storage:</strong> permette, oltre che l’accesso remoto, la condivisione di file fra più host. Una semplice implementazione, per infrastrutture di piccole dimensioni e non molto complesse, può consistere anche di un solo volume NFS (<em>Network File System</em>) montato sulle macchine che devono avere accesso ai file. Tuttavia man mano che le infrastrutture scalano in dimensione diventa necessario usare file system che possa aumentare dinamicamente le proprie dimensioni e migliorare le performance sfruttando parallelamente l’hardware a disposizione.</li>
<li><strong>Block Storage:</strong> espone alle macchine virtuali un dispositivo di archiviazione virtuale, con una interfaccia equivalente ad un disco fisico. Quest’ultima nei sistemi UNIX consiste in un file speciale, in particolare in Linux in un <em>bock device file</em>, tramite il quale le funzionalità dei dispositivi di archiviazione sono accedute tramite le chiamate di sistema per la lettura e scrittura di file. In questo caso l’utente, proprio come nel caso di un disco fisico, può decidere come formattare ed utilizzare il dispositivo. Inoltre in genere quest’ultimo è disponibile sulla rete e condiviso da più host contemporaneamente e l’utente è in grado di gestire questi dispositivi tramite la stessa interfaccia attraverso cui amministra le macchine virtuali.</li>
<li><strong>Object Storage:</strong> non permette l’accesso ai dati di tipo Posix (open, seek, write, close) ma mette a disposizione una serie di IPA per l’accesso e la modifica di questi ultimi. In questo caso non è prevista una struttura a directory ma una organizzazione ad <strong>oggetti</strong>, file binari eventualmente provvisti di metadati, e <strong>bucket</strong>, contenitori in cui scrivere/leggere oggetti (ma non altri bucket, non è infatti possibile costruire alberi di bucket ed esiste un solo livello). Oltre alle IPA è in genere possibile accedere ai file (oggetti) tramite web services sfruttando il protocollo HTTP. Un tipico caso d’uso di questa tipologia di cloud storage è la memorizzazione delle immagini delle macchine virtuali nei Market Place o negli Image Service.</li>
</ul>
<h3 id="esempi-di-tecnologie-disponibili-per-il-cloud-storage">Esempi di tecnologie disponibili per il cloud storage</h3>
<p>Nella seguente tabella sono elencati alcuni esempi di tecnologie disponibili per le varie tipologie di cloud storage</p>
<table>
<thead>
<tr class="header">
<th></th>
<th><strong>Open Stack</strong></th>
<th align="left"><strong>Amazon</strong></th>
<th align="left"><strong>Others</strong></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><strong>Posix Storage</strong></td>
<td>NA</td>
<td align="left">NA</td>
<td align="left">GlusterFS, Lustre, GPFS, CEPH</td>
</tr>
<tr class="even">
<td><strong>Block Storage</strong></td>
<td>Cinder</td>
<td align="left">EBS</td>
<td align="left">CEPH, iSCSI storage</td>
</tr>
<tr class="odd">
<td><strong>Object Storage</strong></td>
<td>Swift</td>
<td align="left">S3</td>
<td align="left">CEPH, GlusterFSUFO</td>
</tr>
</tbody>
</table>
<p>mentre nella seguente tabella sono riassunte alcune caratteristiche delle tipologie di cloud storage per il caso particolare dello stack per il cloud computing open source <strong>Open Stack</strong></p>
<h3 id="caratteristiche-di-un-cloud-storage">Caratteristiche di un cloud storage</h3>
<p>Un servizio di cloud storage possiede le stesse proprietà caratterizzanti di un servizio di cloud computing, ovvero <em>on demand & self service</em>, <em>broad network access</em>, <em>resource pooling</em>, <em>rapid elasticity</em> e <em>measured service</em>. Tuttavia nel caso del cloud storage si aggiungono alcune richieste</p>
<ul>
<li><strong>High availability:</strong> ovvero la ridondanza dei dati e la capacità dei sistemi garantire l’accesso ai dati nonostante la failure di un singolo dispositivo hardware.</li>
<li><strong>High Level API:</strong> possibilità di accesso ai dati, oltre che eventualmente tramite standard POSIX, anche tramite una interfaccia da remoto, standard ed universale (in genere un <em>web service</em>)</li>
</ul>
<p>In una tecnologia di cloud storage fra gli aspetti di maggior rilievo ci sono le interfacce, ovvero il modo con cui viene esposto l’accesso ai file ai livelli di astrazione superiori.</p>
<h1 id="analisi-di-big-data">Analisi di Big Data</h1>
<p>Per <strong>Big Data</strong> si intendono <em>dataset</em> le cui dimensioni trascendono le capacità di hardware e software convenzionali di catturare, gestire o processare dati in tempi ragionevoli. Tuttavia bisogna tenere presente che il concetto di big data è in costante evoluzione e la crescita delle dimensioni effettive dei dataset associati è molto veloce (di alcuni ordini di grandezza in pochi anni).</p>
<h2 id="apache-hadoop">Apache Hadoop</h2>
<p><strong>Apache Hadoop</strong> è un framework software scritto in Java per l’analisi di big data su cluster con le seguenti caratteristiche</p>
<ul>
<li><strong>Scalabile</strong> : nuovi nodi possono essere aggiunti o rimossi <em>a caldo</em>, senza modifiche all’infrastruttura o alle applicazioni che accoglie</li>
<li><strong>Efficiente</strong> : rendendo possibile il calcolo su un sistema ad elevato parallelismo (<em>massively parallel computing</em>) senza l’impiego di hardware specifico</li>
<li><strong>Flessibile</strong> : possibilità di incorporare e scrivere applicazioni per qualsiasi genere di dato, strutturato o meno.</li>
<li><strong>Tollerante ai guasti</strong> : in caso di malfunzionamento di un nodo, perdita di una replica di un file o di un malfunzionamento di un disco, il sistema è in grado di gestire automaticamente il problema</li>
</ul>
<p>Il framework Hadoop comprende</p>
<ul>
<li><strong>Hadoop Common</strong> : le utility e le librerie comuni necessarie agli altri servizi</li>
<li><strong>Hadoop Distributed File System (HDFS)</strong> : un file system in grado di utilizzare risorse distribuite e massimizzare il volume di dati accessibili alle applicazioni</li>
<li><strong>Hadoop YARN</strong> : un framework per lo scheduling dei job e per la gestione delle risorse di archiviazione</li>
<li><strong>Hadoop MapReduce</strong> : un sistema per il calcolo parallelo basato su YARN ed ottimizzato per grandi dataset</li>
</ul>
<p>I problemi riscontrati nella analisi di grandi dataset sono in genere legati al temo di CPU e alla lettura dei dati. La soluzione offerta da Hadoop consiste in un unico framework per la gestione integrata dei processi e dei dati, che cerca di porre rimedio a questi problemi e di risolvere le inefficienze di un approccio tradizionale.</p>
<p>L’osservazione principale è che trasferire i dati verso le CPU (come nel caso tradizionale di macchine separate per l’archiviazione) è sia costoso, per via delle infrastrutture di rete, che inefficiente, per via delle latenze. Una possibile soluzione è scalare il numero di CPU <em>assieme</em> ai dischi e tenere queste ultime il più vicino possibile ai dati da analizzare. Si osserva tuttavia che uno degli svantaggi di questo approccio è che la gestione delle failure diventa più delicata.</p>
<h2 id="hdfs">HDFS</h2>
<p>L’utente può interagire con HDFS in diversi modi</p>
<ul>
<li>montare dischi in userspace (FUSE) simulando un file system di basso livello</li>
<li>monitorare il file system utilizzando una interfaccia Web</li>
<li>utilizzando le API in Java</li>
<li>utilizzando la shell nativa di HDFS da terminale</li>
</ul>
<p>L’architettura del sistema di archiviazione in un cluster Hadoop tramite HDFS comprende i seguenti componenti</p>
<ul>
<li>Uno o più <strong>client</strong> che possono inoltrare richieste al sistema tramite le interfacce citate</li>
<li>Un <em>unico</em> <strong>namenode</strong> che coordina l’archiviazione e la lettura dei dati</li>
<li>Diversi (usualmente centinaia o migliaia) di <strong>datanodes</strong>, che contengono fisicamente i dati</li>
</ul>
<h3 id="scrittura-di-file-in-hdfs">Scrittura di file in HDFS</h3>
<p>La scrittura di un file su HDFS avviene in più fasi</p>
<ol style="list-style-type: decimal">
<li><strong>Request from user</strong> L’utente chiede al client di scrivere un file e fornisce ridondanza desiderata, <strong>replication factor</strong>, e le dimensioni dei blocchi in cui questo verrà diviso dal sistema, <strong>blocksize</strong>.</li>
<li><strong>Client ask namenode</strong> Il client divide il file in blocchi delle dimensioni stabilite e comunica al namenode ridondanza e numero di blocchi</li>
<li><strong>Namenode assignment</strong> Il namenode determina i datanode su cui archiviare i blocchi. Infine restituisce gli indirizzi dei datanode al client (in ordine di distanza dal client crescente)</li>
<li><strong>Client writes data</strong> Il client comincia a scrivere i dati sul primo datanode.</li>
<li><strong>Replication pipeline</strong> Il primo datanode inoltra i dati al secondo e così via, fino all’ultimo datanode</li>
<li><strong>Completion and Inform namenode</strong> Quando l’ultimo datanode finisce di ricevere i dati lo comunica al namenode.</li>
<li><strong>Namenode stores metadata</strong> Ad operazioni concluse il namenode conserva i metadati dei file archiviati sul proprio disco (indirizzi dei namenode, etc.).</li>
</ol>
<p>TODO</p>
<blockquote>
<p>l’idea di hadoop è quello di risolvere i problemi classici che avvengono in un data center. Immaginiamo che ci siano tre copie del mio file e ho due armadi. Conviene che le mie tre copie siano distribuite almeno una su un altro armadio in modo che se uno si spegne comunque un’altra copia sta sull’altro.</p>
</blockquote>
<blockquote>
<p>Chiedo la scrittura ad hadoop specificando la block size e il numero di repliche. Il client specifica queste cose al namenode che è un server che controlla tutto. Il namenode controlla dove è disponibile spazio e scrive il file sul primo datanode che copia poi sull’altro e cosi via. Questo riduce la complessità del client appoggiando una parte dei compiti sul datasystem. Una volta che tutti e tre hanno comunicato al namenode che hanno scritto la procedura è finita. Quindi la velocità effettiva è tre volte più lenta rispetto alla copia singola. Il sistema quindi ha completato la scrittura di quel blocco e si passa al blocco al successivo.</p>
</blockquote>
<blockquote>
<p>Quando il client vuole leggere un file va al namenode e chiede il file. Il namenode comunica con i datanode in parallelo le richieste sui file che comunicano i blocchi presenti di quel file. Il vantaggio è che se un nodo per esempio è occupato o non funziona il sistema può recuperare dagli altri nodi il dato cercato e questo per l’utente è completamente trasparente.</p>
</blockquote>
<blockquote>
<p>Riguardo la placement strategy lui fa questo quando si richiede di fare 3 copie: una replica in un rack e un altra replica in 2 rack. Questo fa si che si minimizzano quanto più possibile l’uso degli up link di rete utilizzando la rete con la connessione interna del rack che è meno costosa. Quindi comunque ho la ridondanza senza aver stressato troppo l’up link. Inoltre questi sistemi vengono utilizzati per scrivere poco e leggerli molte volte. Quindi avere due copie all’interno dello stesso rack fa si che quando vado a fare analisi potrei leggere al doppio della velocità utilizzando le due copie all’interno dello stesso rack.</p>
</blockquote>
<h2 id="map-reduce">Map Reduce</h2>
<p>TODO</p>
</body>
</html>