ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

BAN QUẢN LÝ DỰ ÁN 11-P04-VIE

-----------------

Dự án

NGHIÊN CỨU THUỶ TAI DO BIẾN ĐỔI KHÍ HẬU

VÀ XÂY DỰNG HỆ THỐNG THÔNG TIN NHIỀU BÊN THAM GIA

NHẰM GIẢM THIỂU TÍNH DỄ BỊ TỔN THƯƠNG

Ở BẮC TRUNG BỘ VIỆT NAM (CPIS) Mã số: 11.P04.VIE

(Thuộc Chương trình thí điểm hợp tác nghiên cứu

Việt Nam - Đan hạch 2012-2015)

BÁO CÁO KẾT QUẢ THỰC HIỆN NĂM 2012-2013

Nội dung 3: Tổ chức thực hiện CPIS

Nhóm nghiên cứu: WP6

Chủ dự án: Trường Đại học Khoa học Tự nhiên

Giám đốc dự án: GS. TS. Phan Văn Tân

Những người thực hiện:

Trưởng nhóm: ThS. Nguyễn Trung Kiên

Các thành viên: TS. Bùi Quang Thành

CN. Nguyễn Quốc Huy

ThS. Phan Văn Trọng

CN. Đoàn Thị The

2

Tổ chức thực hiện CPIS

Họ và tên chuyên gia: Nguyễn Quốc Huy

1. Mở đầu

Hệ thống thông tin là sản phẩm trực quan và gần gũi với người sử dụng nhất

trong khuôn khổ dự án “Nghiên cứu thuỷ tai do biến đổi khí hậu và xây dựng hệ thống

thông tin nhiều bên tham gia (CPIS) nhằm giảm thiểu tính dễ bị tổn thương ở Bắc

Trung Bộ Việt Nam”. Hệ thống này được thiết kế để lưu trữ một lượng dữ liệu lớn với

nhiều định dạng khác nhau, được thu thập bởi các nhóm nghiên cứu trong suốt quá

trình thực hiện cũng như vận hành.Đi cùng với việc lưu trữ, hệ thống cũng cần cung

cấp các cơ chế cho các nhà khoa học truy cập vào khối dữ liệu để xử lý, phân tích,

trích suất thông tin, tổng hợp lại thành cơ sở dữ liệu tri thức. Và cuối cùng, chức năng

quan trọng nhất của hệ thống là truyền tải thông tin mà trung tâm là WebGIS, lồng

ghép kiến thức bản địa nhằm giúp người dân ứng phó với thuỷ tai do biến đổi khí hậu

gây ra nhằm giảm thiểu những tổn thất về tính mạng và tài sản.

Trong báo cáo này, chúng tôi tập trung vào việc triển khai hệ thống lưu trữ đáp

ứng yêu cầu lưu trữ lượng dữ liệu lớn với băng thông cao và ổn định. Việc triển khai

WebGIS cùng với thành phần truyền thông của hệ thống sẽ được trình bày kĩ trong các

báo cáo khác.

2. Sơ lược thiết kế hệ thống CPIS

CPIS phục vụ 3 nhóm đối tượng chính: các nhà khoa học, những người làm

chính sách và cộng đồng. Hệ thống cần đáp ứng được ba chức năng:

(i) lưu trữ các loại dữ liệu khác nhau;

(ii) giúp các nhà khoa học truy cập, phân tích dữ liệu; và

(iii) truyền tải thông tin đến cộng đồng người sử dụng.

Dữ liệu đầu vào có thể có các loại định dạng khác nhau, bao gồm số liệu định

lượng và dữ liệu “kiến thức bản địa” nhận được từ cộng đồng. Dữ liệu có thể ở dạng

ảnh, phim, bản vẽ, ảnh vệ tinh, văn bản, sản phẩm dự báo các loại. Lượng dữ liệu rất

lớn này sau đó sẽ được số hóa, chuẩn hóa, không gian hóa và tích hợp vào cơ sở tri

thức dựa trên GIS.

Các nhà khoa học có thể sử dụng các ứng dụng qua mạng nội bộ để truy cập đến

hệ thống thông tin, phân tích dữ liệu và trích rút các thông tin cần thiết. Hệ thống cũng

cần cho phép người dùng tìm kiếm và tạo tài liệu lưu trữ trên đĩa quang (CD, DVD),

bản đồ và sách để gửi cho cộng đồng bị hạn chế trong việc truy cập Internet, nhất là

khi có thiên tai xuất hiện.

Đối với đông đảo cộng đồng người sử dụng, hệ thống cho phép truy cập cơ sở tri

thức bằng trình duyệt web (trên PC hoặc điện thoại di động) qua Internet. Website cần

được thiết kế để có thể truy cập được theo các mức ưu tiên khác nhau cho các nhà

khoa học, các nhà quản lý và cộng đồng địa phương. Giao diện của website phải được

xây dựng sao cho thân thiện, mềm dẻo với người sử dụng để họ có thể truy cập và

phản hồi thông tin của họ. Thông qua quá trình tinh chỉnh liên tiếp (các phân tích số

3

liệu từ các nhà khoa học, thông tin thẩm định và phản hồi từ người sử dụng) thông tin

trong hệ thống sẽ được chứng thực và ngày càng được làm giàu thêm.

Dựa trên thông tin thu thập về nhu cầu của 3 nhóm hưởng lợi có được qua các

bản khảo sát cùng với yêu cầu chung về thệ thống CPIS, chúng tôi đã lên một thiết kế

cơ sở cho hệ thống CPIS dựa trên GIS [Hình 1].

Hình 1. Kiến trúc hệ thống CPIS

Hệ thống có thể được chia thành 2 cụm PUBLIC và PRIVATE. Cụm PRIVATE

bao gồm cluster (để chạy các mô hình khí tượng, thuỷ văn), các server dịch vụ

(Database, Geo, Web, FTP), các máy trạm xử lý dữ liệu và mạng kết nối. Cụm

PUBLIC bao gồm thành phần cơ bản là Website để người dùng tương tác. Các thành

phần trong cụm PRIVATE chỉ có thể được truy cập bởi các thành viên thực hiện dự án

(các nhà khoa học). Cụm PUBLIC (website) được sử dụng bởi rộng rãi người dùng

(cộng đồng, nhà quản lý, nhà khoa học).

Cụm PRIVATE bao gồm các thiết bị và dịch vụ đáp ứng yêu cầu (i) và (ii) của

CPIS, tức lưu trữ dữ liệu và cung cấp cơ chế truy cập để xử lý và phân tích. Cụm

PUBLIC chỉ gồm các dịch vụ hướng tới người dùng cuối như máy chủ web và

website.

3. Triển khai hệ thống CPIS

3.1. Xây dựng hệ thống lưu trữ hiệu năng cao Lustre

a) Thử nghiệm trên hệ thống sẵn có

4

Để chứng minh khả năng vượt trội của Lustre so với hệ thống lưu trữ tập trung,

chúng tôi xây dựng môi trường thử nghiệm như mô tả trong [Hình 2].

Trong thử nghiệm này một máy chủ được sử dụng làm NFS server với phân vùng

lưu trữ được đặt trên một Hardware RAID 5 - xây dựng trên 3 ổ SATA 1TB và chia sẻ

qua NFS. NFS server này cũng đóng vai trò máy chủ MDS cho hệ thống Lustre. 3

node tính toán đóng vai trò làm NFS client, đồng thời làm OSS và Lustre client. Các

đĩa cứng đơn trên node tính toán tương tự đĩa cứng sử dụng trên NFS server. Thông số

stripe_count được cấu hình bằng 3, tức mỗi tập tin sẽ được chia ra thành các phân

đoạn dữ liệu lưu trữ trên cả 3 node; stripe_size được đặt mặc định.

Chương trình tính toán chạy trên hệ thống thử nghiệm là mô hình MM5, được

cấu hình để mô phỏng khí hậu trong 1 tháng. Có tất cả 24 tiến trình MPI chạy trên 3

node tính toán, sau mỗi bước thời gian mô phỏng 1 ngày, mỗi tiến trình sẽ ghi một tập

tin có dung lượng khoảng 1 GB lên hệ thống.

Hình 2. Cấu hình thử nghiệm khả năng đáp ứng tính toán song song

Các đồ thị trong [Hình 3] được lấy từ hệ thống giám sát cluster - Ganglia

Monitor. Trong phần đồ thị tương ứng với thử nghiệm chạy MM5 trên NFS, cứ sau

một khoảng thời gian, cả 24 bộ xử lý trên 3 node tính toán đều giảm hoạt động do dữ

liệu được chuyển qua mạng kết nối cho NFS server để ghi vào ổ cứng. Băng thông

vào/ra ghi nhận được trên mạng kết nối đạt được khoảng 50 MB/s. Trong trường hợp

thử nghiệm ghi dữ liệu kết xuất của MM5 trên Lustre, băng thông vào/ra có lúc đạt

được tới 80 MB/s, còn lại là hầu như lớn hơn 50 MB/s. Thời gian ghi dữ liệu vào hệ

thống tập tin Lustre nhỏ hơn so với NFS nên thời gian giảm hoạt động của các bộ xử

lý giảm đi đáng kể, dẫn tới hiệu suất đạt được trên hệ thống tính toán cũng tăng lên

đáng kể. Thời gian ghi dữ liệu giảm có thể giải thích vì Lustre cho phép các máy

khách ghi dữ liệu song song cùng một lúc.

5

Hình 3. Kết quả thử nghiệm so sánh NFS (trái) với Lustre (phải)

b) Triển khai hệ thống lưu trữ Lustre phục vụ tính toán song song

Thử nghiệm trong phần trên cho thấy rằng Lustre đáp ứng tốt nhiệm vụ làm hệ

thống lưu trữ phục vụ tính toán các bài toán Khí tượng, khí hậu. Tuy nhiên, do hệ

thống vẫn sử dụng mạng kết nối 1 Gbps, băng thông vào/ra trên hệ thống chưa phát

huy được khả năng của Lustre. Thêm nữa, do phân tích ở phần trên, để đảm bảo tính

toàn vẹn của dữ liệu, các OST được đặt trên các Hardware RAID 5(0), băng thông vào

ra sẽ vượt ra ngoài khả năng truyền tải của mạng kết nối khiến mạng kết nối trở thành

nút "cổ chai" trong hệ thống lưu trữ. Chính vì vậy, trong hệ thống lưu trữ mới, chúng

tôi quyết định nâng mạng kết nối lên Infiniband 10Gbps [Hình 4].

Hình 4. Hệ thống lưu trữ Lustre

2 máy chủ lưu trữ được bổ sung vào hệ thống đóng vai trò làm OSS. Mỗi OSS có

24 GB RAM, được gắn 25 ổ cứng SATA 3 Enterprise, mỗi ổ có dung lượng 2TB. 25 ổ

cứng này được cấu hình với hardware RAID 50 + Hot spare và được chia thành 4 phân

vùng, tương ứng với 4 OST. Máy chủ IBM được nâng cấp RAM lên 8 GB đóng vai trò

máy chủ MDS. Tổng dung lượng lưu trữ của hệ thống đạt khoảng 80 TB với băng

thông đạt khoảng 1 GB/s.

3.2. Xây dựng hệ thống HDFS phục vụ sao lưu dữ liệu

a) HDFS

Apache Hadoop

6

Apache Hadoop là một nền tảng phần mềm nguồn mở hỗ trợ các chương trình

phân tán xử lý lượng số liệu cực lớn cỡ hàng trăm TB cho tới hàng PB. Tiền thân của

Apache Hadoop bắt nguồn từ một dự án cá nhân, xây dựng máy tìm kiếm mã mở

(Nutch) của Doug Cutting vào năm 2002. Trong 2 năm đầu tiên, Doug gặp rất nhiều

khó khăn trong việc tăng quy mô lưu trữ và xử lý khối lượng dữ liệu web lớn cho

Nutch. Tới khoảng năm 2004, được truyền cảm hứng từ một bài báo của Google về

MapReduce và GFS, Doug Cutting phát triển phiên bản mã mở Hadoop MapReduce

và HDFS tương ứng. Năm 2006, Hadoop tách khỏi Nutch và trở thành dự án mã mở

cấp cao của Apache vào năm 2008.

HDFS

HDFS - Hadoop Distributed File System - là một hệ thống file phân tán được

thiết kế cho các hệ thống sử dụng thiết bị thông thường (tức những thiết bị tương

đương với thiết bị của nhóm nghiên cứu). HDFS tuy có rất nhiều điểm chung với các

hệ thống file phân tán hiện có nhưng cũng chứa nhiều điểm khác biệt. Một trong số đó

là HDFS có khả năng chịu lỗi cao, được thiết kế để chạy trên các phần cứng rẻ tiền và

đặc biệt đảm bảo được tính toàn vẹn của dữ liệu khi một phần trong số các phần cứng

gặp lỗi.

Kiến trúc của HDFS

HDFS có kiến trúc chủ - tớ (master - slave). Một hệ thống HDFS [Hình 5] bao

gồm một Namenode duy nhất (master) - máy chủ quản lý không gian tên của hệ thống

tập tin và điều tiết việc truy xuất tập tin của các máy khách (client). Các thiết bị lưu trữ

được quản lý bởi các Datanode (slave) - chương trình chạy trên các máy chứa thiết bị

lưu trữ. HDFS tương tác với máy khách qua không gian tên, cho phép lưu trữ dữ liệu

của người dùng dưới dạng các tập tin.

Hình 5. Kiến trúc HDFS

Bên trong HDFS, tập tin được chia ra thành một hoặc nhiều khối (block) dữ liệu

(mặc định là 64MB) và rồi các block này được lưu trữ trên một tập các Datanode.

Namenode là nơi chứa siêu dữ liệu, đồng thời đảm nhận các thao tác trên không gian

tên như mở, đóng và thay đổi tên tập tin và thư mục. Namenode cũng xác định ánh xạ

giữa các block dữ liệu với các Datanode (block nào nằm trên Datanode nào). Các

Datanode chịu trách nhiệm đáp ứng các yêu cầu đọc/ghi của người dùng từ các máy

7

khách. Chúng cũng thực hiện việc khởi tạo, xoá và sao chép các block dữ liệu theo chỉ

lệnh từ Namenode.

Được thiết kế để triển khai trên các hệ thống phần cứng thông dụng, với các

thành phần phần cứng có tần suất gặp lỗi cao, HDFS đảm bảo độ tin cậy bằng cách tự

động sao chép các block dữ liệu lên các Datanode khác nhau. Số lượng các bản sao

của các block dữ liệu được duy trì trong hệ thống phụ thuộc vào một hệ số gọi là hệ số

nhân (replication factor). Hệ số này được ấn định khi khởi tạo một tập tin và hoàn toàn

có thể thay đổi về sau theo chủ ý của người dùng. [Hình 6] mô tả các block với các

datanode tương ứng trong hệ thống có hệ số nhân bằng 3.

Việc lưu nhiều bản sao của một block dữ liệu trên hệ thống là chiến thuật đơn

giản để đảm bảo tính chịu lỗi của HDFS. Namenode quyết định toàn bộ việc sao chép

các block dữ liệu. Cứ 3 giây 1 lần, Namenode nhận tín hiệu Heartbeat và dữ liệu báo

cáo block (Blockreport) từ các Datanode. Nhận được Heartbeat từ một Datanode có

nghĩa là node đó vẫn hoạt động bình thường; còn Blockreport chứa danh sách các

block trên Datanode. Nếu sau 10 phút mà Namenode không nhận được Heartbeat từ

một Datanode, Datanode đó được coi là chết, Namenode sẽ xác định các block dữ liệu

được lưu trên node đó rồi yêu cầu node có chứa block dữ liệu tương ứng còn sống thực

hiện việc sao chép lên một node khác ([Hình 7]). Quá trình sao chép cũng xảy ra tương

tự trong trường hợp Namenode nhận thấy 1 block dữ liệu không thể truy cập được.

Nếu node bị chết khôi phục được hoạt động hay block dữ liệu lại có thể truy cập được,

số lượng bản sao của block trên hệ thống vượt quá hệ số nhân, Namenode sẽ lựa chọn

Datanode tương ứng rồi ra lệnh huỷ bản sao.

Hình 6. Sao chép block dữ liệu khi tạo

tập tin

Hình 7. Sao chép block dữ liệu khi

lượng bản sao giảm xuống dưới hệ số nhân

Với thiết kế này, siêu dữ liệu và dữ liệu trên HDFS được lưu trữ tách biệt nhau.

Siêu dữ liệu, bao gồm các thông tin về tập tin, cấu trúc cây thư mục và vị trí các block

dữ liệu, được lưu trữ trên Namenode. Các block dữ liệu được lưu trên các Datanode.

Mọi yêu cầu ghi hoặc truy vấn dữ liệu từ các máy khách bắt đầu bằng việc gửi yêu cầu

đến Namenode. Sau khi Namenode gửi trả lại cho máy khách danh sách các Datanode,

dữ liệu sẽ được truyền trực tiếp giữa máy khách và các Datanode. Theo cách này, thời

gian tìm kiếm vị trí dữ liệu (seek time) sẽ lâu hơn các phương pháp lưu trữ thông

thường trên một kho lưu trữ trung tâm (centralized storage); nhưng băng thông truyền

dữ liệu theo dòng tổng cộng sẽ tăng tuyến tính với số lượng Datanode trong hệ thống.

Một điểm khác biệt nữa giữa HDFS và các hệ thống tập tin thông thường khác là

HDFS không hoàn toàn tương thích chuẩn POSIX. Khi đọc dữ liệu, HDFS vẫn cho

8

phép truy cập ngẫu nhiên nhưng khi ghi, HDFS chỉ hỗ trợ ghi tuần tự; HDFS cũng

không cho phép nhiều ứng dụng ghi cùng lúc vào một tập tin. Nói một cách tóm lược,

HDFS là lựa chọn thích hợp cho các ứng dụng ghi-một-lần-đọc-nhiều-lần trên các tập

tin có dung lượng lớn với băng thông đọc cao và độ trễ truy xuất dữ liệu chấp nhận

được.

DFS-FUSE (Hay MountableHDFS)

Một ứng dụng có thể truy cập dữ liệu trong HDFS bằng nhiều cách khác nhau.

Về nguyên bản, HDFS được viết trên nền JAVA nên người dùng có thể sử dụng giao

diện lập trình ứng dụng (API) để truy xuất dữ liệu. Tuy nhiên, đơn giản nhất cho một

người sử dụng thông thường là khả năng mount hệ thống tập tin HDFS vào cây thư

mục của hệ điều hành. DFS-FUSE [6] là một dự án ra đời với mục tiêu như vậy. Khi

HDFS đã được mount vào hệ thống (biểu hiện dưới dạng một thư mục), người dùng có

thể thao tác trên đó bằng các lệnh Unix chuẩn như 'ls', 'cd', 'cp', 'mkdir', 'find', 'grep',

hoặc sử dụng các thư viện POSIX chuẩn như open, write, read, close với các ngôn ngữ

lập trình C, C++, Fortran, Python, Perl, Java, Shell, ...

b) Sự quan trọng của Siêu dữ liệu

Đối với người quản trị hệ thống HDFS, họ phải hiểu một điều rằng Siêu dữ liệu

trên Namenode là những bit thông tin quý giá nhất mà họ cần bảo vệ. Hệ thống HDFS

có thể chứa đến hàng trăm TB dữ liệu, trải ra trên hàng triệu block dữ liệu và chứa trên

hàng nghìn Datanode; nhưng Siêu dữ liệu, thường chỉ có độ lớn từ vài chục MB đến

vài chục GB chính là chìa khoá cho phép số thông tin khổng lồ đó ghép nối lại với

nhau thành các tập tin có nghĩa. Một khi Siêu dữ liệu bị mất, cả hệ thống HDFS với

hàng triệu block dữ liệu rời rạc trở thành vô giá trị. Chính vì vậy, Siêu dữ liệu cần phải

được sao lưu một cách thường xuyên.

Để tăng tốc tìm kiếm, Siêu dữ liệu được lưu trực tiếp trong bộ nhớ của

Namenode. Namenode đồng thời cũng lưu hai cấu trúc dữ liệu lên ổ cứng để đảm bảo

sự ổn định của Siêu dữ liệu. Cấu trúc đầu tiên được lưu là bản sao của Siêu dữ liệu

trong bộ nhớ Namenode - fsimage, cấu trúc thứ hai là nhật ký những thay đổi kể từ lần

sao lưu gần nhất - edits. Ngoài Namenode, hệ thống HDFS còn duy trì một Namenode

phụ (Secondary Namenode - 2NN) làm nhiệm vụ định kì nạp fsimage và edits từ

Namenode, thực hiện các thay đổi trong edits lên fsimage rồi gửi lại cho Namenode.

Namenode nhận fsimage từ 2NN thay thế Siêu dữ liệu trong bộ nhớ, xoá nhật ký edits

và đưa quy trình về lại ban đầu. Khi HDFS được khởi động, Namenode cũng sẽ tìm

đến 2 tập tin fsimage và edits từ vị trí được thiết lập trong cấu hình, thực hiện thay đổi

trong edits lên fsimage rồi đọc Siêu dữ liệu vào bộ nhớ. Như vậy, việc sao lưu Siêu dữ

liệu có thể thực hiện bằng cách sao lưu 2 cấu trúc dữ liệu này.

c) Ứng dụng HDFS trong sao lưu dữ liệu

Hiện trong thực tế chưa có giải pháp toàn diện cho một hệ thống sao lưu dữ liệu

dựa trên HDFS. Tuy nhiên, dựa trên kiến trúc thiết kế và những phản hồi tích cực từ

phía người sử dụng về độ ổn định và an toàn của hệ thống, chúng ta có thể tin tưởng

rằng HDFS hoàn toàn đáp ứng được yêu cầu của một hệ thống lưu trữ dữ liệu sao lưu.

Facebook, Yahoo là hai trong số hàng trăm công ty hàng đầu thế giới đang sử dụng

HDFS để lưu trữ dữ liệu phục vụ kinh doanh [7]. Còn theo báo cáo của Dhruba

Borthakur thủ lĩnh dự án Apache HDFS, Facebook cũng sao lưu toàn bộ cơ sở dữ liệu

MySQL lên hệ thống HDFS của họ [5].

9

d) HDFS phục vụ CPIS

Mã nguồn Hadoop được chia sẻ miễn phí và người dùng có thể tải về sử dụng từ

website của Apache. Ngoài Apache, một vài công ty độc lập cũng phát hành phiên bản

riêng của họ, kết hợp Apache Hadoop với các tiện ích được phát triển bởi cộng đồng

sử dụng. Nhóm nghiên cứu đã triển khai phiên bản hadoop-0.20.2-cdh3u2 của

Cloudera [8] lên hệ thống cluster của mình [Hình 8].

Hình 8. Hadoop Cluster tại Remoclic

Hệ thống hiện tại có dung lượng tổng cộng 50TB với hệ số nhân mặc định được

cấu hình bằng 2. Do dung lượng của siêu dữ liệu HDFS chỉ vào khoảng 80MB nên bộ

nhớ của Namenode (8GB) là hoàn toàn đáp ứng được.

Hầu hết dữ liệu trên hệ thống là những tập tin có dung lượng lớn và không thay

đổi nội dung trong quá trình tồn tại nên chúng tôi lựa chọn mô hình sao lưu không cấu

trúc. Việc sao lưu có thể thực hiện thủ công hoặc tự động bằng các script bash shell.

Để sao lưu Siêu dữ liệu, chúng tôi cấu hình Namenode cho ghi fsimage và edits

ra nhiều ổ cứng khác nhau trên hệ thống. Tuy nhiên, việc sao lưu này là chưa đủ độ tin

cậy. Thực tế cho thấy rằng, sự bất cẩn của người dùng cũng là một trong số nguyên

nhân chính gây ra mất mát dữ liệu. Một trường hợp hiếm nhưng có thể xảy ra là quản

trị hệ thống chạy nhầm lệnh: hadoop fs -rmr /. Với lệnh này, toàn bộ thông tin về

thư mục và tập tin trong hệ thống sẽ bị xoá khỏi Siêu dữ liệu của HDFS trên

Namenode (các block dữ liệu chưa bị xoá ngay lập tức khỏi các Datanode). Tất cả các

bản sao fsimage và edits sau một khoảng thời gian nhất định sẽ được cập nhật và

người dùng sẽ mất tất cả thông tin. Đề phòng trường hợp này, chúng tôi đã tìm ra giải

pháp tự động sao lưu fsimage và edits theo mô hình sao lưu tăng dần, sử dụng không

gian lưu trữ trực tuyến của Dropbox. Dropbox cho phép người dùng lấy lại tập tin đã

mất, phục hồi thông tin từ quá khứ với các thay đổi trong thời gian tới 1 tháng [Hình

9]. Và với dung lượng lưu trữ miễn phí 2GB, hệ thống của chúng tôi có thể an toàn mở

rộng ra tới hàng trăm TB.

10

Hình 9. Giao diện Dropbox dùng để phục hồi tập tin

3.3. Triển khai WebGIS

Như đã trình bày trong phần thiết kế, WebGIS được xây dựng dựa trên các thành

phần mã nguồn mở cơ bản PostGIS, GeoServer, GeoWebCache, GeoExt và

OpenLayers. Việc triển khai WebGIS bao gồm các công đoạn:

Thiết lập danh mục dữ liệu

Thiết kế mô hình dữ liệu

Chuẩn hoá dữ liệu nền địa lý khu vực nghiên cứu

Thu thập và lưu trữ dữ liệu trong cơ sở dữ liệu

Xây dựng các công cụ phục vụ hiển thị trên nền Web

Tài liệu hoátiến trình triển khai với nhiều công đoạn cùng các kĩ thuật tiến hành

khác nhau sẽ được tách ra trong các báo cáo riêng. Người đọc có thể tìm hiểu tiến trình

này trong các báo cáo tương ứng.

3.4. Triển khai hệ thống truyền thông

Hệ thống truyền thông bao gồm hai thành phần: mạng kết nối và website dịch vụ.

Hệ thống được thiết kế và xây dựng để phục vụ lượng không nhỏ người dùng. Vì lý do

này, việc đảm bảo kết nối thông suốt cần được đặt lên hàng đầu. Hệ thống được cấu

hình để kết nối với Internet qua hai đường liên kết chính. Đường thứ nhất được cung

cấp bởi VNPT với băng thông lên tới 40Mbps, đường thứ hai cung cấp bởi Đại học

Quốc Gia Hà Nội với băng thông cao nhất đạt 30Mbps. Cả hai đường kết nối đều là

cáp quang, cho độ ổn định cũng như tuổi thọ cao. Hai đường kết nối này được cấu

hình cân bằng tải với router Draytek 3900 [Hình 10].

Hình 10. Router Draytek 3900

11

Website của dự án được xây dựng hoàn toàn từ phần mềm mã nguồn mở, bao gồm

các thành phần chính Apache webserver, PHP và MySQL [Hình 11].Tất cả các thành

phần của hệ thống truyền thông bao gồm dịch vụ máy chủ Web, website, MySQL

server, PostGIS, GeoServer, ... được lưu trữ trên một máy chủ trung tâm chạy hệ điều

hành CentOS cùng với phương án ảo hoá sử dụng Xen.

Hình 11. Website truyền thông của dự án

4. Kết luận

Hệ thống thông tin là kết quả trực quan và gần gũi người sử dụng nhất của dự án

“Nghiên cứu thuỷ tai do biến đổi khí hậu và xây dựng hệ thống thông tin nhiều bên

tham gia (CPIS) nhằm giảm thiểu tính dễ bị tổn thương ở Bắc Trung Bộ Việt Nam”.Hệ

thống cần đáp ứng khả năng lưu trữ lớn với băng thông cao để phục vụ việc lưu trữ

nhiều dạng dữ liệu khác nhau và đặc biệt là phục vụ hệ thống tính toán hiệu năng cao,

dự báo khí hậu. Hệ thống cũng cần được kết nối một cách ổn định với Internet để phục

vụ việc truy cập của người sử dụng mà phần lớn là người dân ở những vùng chịu ảnh

hưởng của thuỷ tai do biến đổi khí hậu.

Trong báo cáo này, chúng tôi đã trình bày việc triển khai hệ thống lưu trữ Lustre,

HDFS với dung lượng rất lớn cùng băng thông cao phục vụ cho CPIS. Chúng tôi cũng

trình bày sơ qua việc triển khai WebGIS và hệ thống truyền thông mà trọng tâm là

12

Website của dự án. Chi tiết việc triển khai các thành phần này có thể tìm thấy trong

các báo cáo tương ứng.

5. Tài liệu tham khảo

[1]. The Diverse and Exploding Digital Universe, IDC White Paper, March 2008 -

http://www.emc.com/collateral/analyst-reports/diverse-exploding-digital-universe.pdf

[2]. Kabooza Global Backup Survey - http://www.kabooza.com/globalsurvey.html

[3]. Backup article on Wiki - http://en.wikipedia.org/wiki/Backup

[4]. HDFS Design - http://hadoop.apache.org/hdfs/docs/current/hdfs_design.html

[5]. Apache Hadoop FileSystem and its Usage in Facebook - Dhruba Borhakur, April 4,

2011 - http://cloud.berkeley.edu/data/hdfs.pdf

[6]. MountableHDFS - Hadoop Wiki, http://wiki.apache.org/hadoop/MountableHDFS

[7]. PowerdBy - Hadoop Wiki, http://wiki.apache.org/hadoop/PoweredBy

[8]. Cloudera - http://cloudera.com