Windows Azure là một hệ điều hành quản lý cả các server và các dịch vụ. Windows Azure chạy trên các hệ điều hành Windows server 2008 R2 với hỗ trợ Hyper- V. Có thể coi Windows Azure là một hệ điều hành ảo chứa nhiều máy ảo chạy trên phần cứng có khả năng co giãn rất lớn nhưng đã được ảo hóa. Sự ảo hóa giữa các dịch vụ nhân của Windows Azure và phần cứng được quản lý bởi Fabric Controller. Fabric controller quản lý quá trình tự động hóa đầu cuối (end-to-end) của các dịch vụ Windows Azure, từ việc cung cấp phần cứng cho đến việc duy trì sự sẵn sàng của dịch vụ. Hình 2.3 minh họa vai trò của Fabric Controller trong kiến trúc Windows Azure:
Hình 2.3 Vai trò của Fabric Controller trong Windows Azure
Windows Azure được thiết kế để có độ sẵn sàng rất cao, cũng như khả năng co giãn rất lớn. Trong hình trên, Fabric Controller đọc thông tin cấu hình của dịch vụ do dịch vụ cloud cung cấp và tương ứng tạo các máy chủ ảo cần thiết để triển khai dịch vụ. Sự triển khai các dịch vụ cloud và sinh các instance máy chủ ảo hoàn toàn trong suốt đối với nhà phát triển. Nhà phát triển chỉ thấy trạng thái của việc triển khai dịch vụ cloud trên Windows Azure developer portal. Một khi dịch dụ cloud đã được triển khai, nó được quản lý hoàn toàn bởi Windows Azure. Nhà phát triển chỉ cần xác định trạng thái cuối cùng của dịch vụ cloud trong file cấu hình của nó, Windows Azure sẽ cung cấp phần cứng và phần mềm cần thiết để thực hiện điều đó. Nói cách khác, các công việc triển khai khả năng co giãn, độ sẵn sàng, cập nhật và cấu hình phần cứng được quản lý bởi
Windows Azure.
Trong phần trước, chúng ta thấy rằng Windows Azure bao gồm 3 dịch vụ chính: Tính toán - compute, lưu trữ - storage và quản lý - management.
Dịch vụ tính toán cung cấp hosting cho các ứng dụng web trên nền IIS và các tiến trình .NET chạy nền. Các ứng dụng web được gọi là web role, và các tiến trình chạy nền được gọi là Worker role. Woker role tương tự như các dịch vụ Windows (Windows
Services) và được thiết kế đặc biệt cho việc xử lý nền (background processing). Một dịch vụ cloud trên Windows Azure bao gồm một Web role và/hoặc một Woker role cùng với các định nghĩa của dịch vụ.
Dịch vụ lưu trữ trên Windows Azure hỗ trợ 3 kiểu dịch vụ: blob, queue và table, các kiểu lưu trữ này hỗ trợ truy cập cục bộ hay trực tiếp thông qua REST API. Bảng dưới đây minh họa sự khác biệt giữa 3 kiểu lưu trữ này:
Tính
năng Blob Queue Table
Lược đồ
URL http://[Storage Account].blob.core.w ndows.net/[Container Name]/[Blob Name] http://[Storage Account].queue.core.w indows.net/[Queue Name] http://[Storage Account].table.core.windows. net/[Table Name]?$filter=[Query] Kích thước tối đa
50GB 8KB (string) Được thiết kế cho dữ liệu
hàng TB Nên dùng cho Các kiểu dữ liệu nhị phân lớn
Giao tiếp message giữa các service
Lưu trữ các đối tượng có cấu trúc nhỏ hơn như trạng thái người dùng qua các sessions
API http://msdn.microsoft .com/en- us/library/dd135733.a spx http://msdn.microsoft .com/en- us/library/dd179363.a spx http://msdn.microsoft.com/en -us/library/dd179423.aspx
Bảng 2.4: Đặc tính 3 kiểu lưu trữ trong Windows Azure Storage
Hình 2.5: Kiến trúc tổng thể hệ điều hành Windows Azure
Có thể thấy các dịch vụ tính toán và lưu trữ là các dịch vụ độc lập với nhau trong
Windows Azure. Web và Woker role chạy trong Compute Service, và các dịch vụ blob, queue, table chạy trên Storage service. Fabric Controller trừu tượng hóa các thành phần của cơ sở hạ tầng phía dưới như máy chủ ảo, các thành phần mạng, DNS và các bộ cân bằng tải đối với Compute và Storage. Khi một request từ Internet đến một ứng dụng Web role, nó thông qua bộ cân bằng tải tới Web role của Compute Service. Nếu một request yêu cầu dịch vụ Storage, nó thông qua bộ cân bằng tải đến thành phàn của Storage service thích hợp. Ngay cả khi một Web hay Woker role cần phải giao tiếp với Storage
service, nó phải dùng cùng REST API mà các ứng dụng client khác sử dụng. Cuối cùng, các dịch vụ Compute và Storage có thể được quản lý bởi Service Management API.
2.1.1Compute Service
Compute là một trong những dịch vụ cốt lõi của Windows Azure. Nó cũng được gọi là Hosted Service trong thuật ngữ của Windows Azure portal. Compute Service cung cấp khả năng phát triển và triển khai các dịch vụ cloud, với nền tảng phía dưới bao gồm .NET 3.5 SP1 Framework và IIS 7 chạy trên các máy chủ cài Windows Server 2008 64-bit. Nhà phát cũng có thể xây dựng các ứng dụng native truyền thống.
Mục đích của Compute Service là cung cấp khả năng chạy các ứng dụng phục vụ cùng lúc rất nhiều người dùng. Điều này không thể đạt được nếu chỉ dùng các máy tính to hơn – co giãn theo kiểu scale up. Thay vào đó, Compute Service sử dụng cách tiếp cận
scale out, tức là sử dụng nhiều máy chủ chạy đồng thời với nhau.
Một ứng dụng chạy trên Compute Service gồm có 2 thành phần cơ bản: Web role và worker role
Web role:
Một web role là một website hay một web service có thể chạy trên môi trường IIS 7. Thông thường, nó sẽ là một ứng dụng web trên ASP.NET hoặc là một dịch vụ
Windows Communication Foundation (WCF) với các endpoint HTTP và/hoặc HTTPS.
Hiện thời các giao thức kết nối vào (inbound protocol) được hỗ trợ là HTTP và HTTPS, và giao thức kết nối ra (outbound protocol) là bất kì socket TCP nào. Giao thức kết nối ra UDP hiện chưa được hỗ trợ bởi các dịch vụ của Windows Azure. (adsbygoogle = window.adsbygoogle || []).push({});
Web role đồng thời hỗ trợ module mở rộng dạng FastCGI cho IIS 7.0. Điều này cho phép các nhà phát triển xây dựng các ứng dụng web sử dụng các ngôn ngữ thông dịch như PHP và ngôn ngữ native như C++. Windows Azure hỗ trợ thực thi dạng tin
không giữ trạng thái – stateless. Tất cả các thông tin gắn với người dùng phải được lưu vào Windows Azure storage hoặc trả lại người dùng.
Chú ý: Mặc dù Windows Azure hỗ trợ thực thi code native, code vẫn chỉ chạy với quyền người dùng, không phải quyền quản trị, vì vậy một số hàm Win32 API yêu cầu quyền quản trị sẽ không truy cập được.
Woker role:
Worker role cung cấp khả năng chạy một tiến trình nền liên tục trên cloud. Worker role có thể mở các endpoint, cũng như gọi các giao tiếp bên ngoài. Về nguyên tắc, Woker role giống như một web role, trừ việc nó không tương tác với IIS và cũng không có giao diện. Một Woker role có thể giao tiếp với các dịch vụ queue, blob, và table của Windows Azure. Một instance của Woker role chạy độc lập với instance của Web role, mặc dù chúng có thể là các phần khác nhau của cùng một dịch vụ. Một Woker role chạy trên máy ảo riêng biệt với web role trong cùng một service. Trong một số dịch vụ Windows Azure, có thể cần giao tiếp giữa một Web role và một Woker role. Mặc dù cả Web và woker role đều mở các endpoint cho giao tiếp, nhưng cách đơn giản và đáng tin cậy nhất là sử dụng Windows Azure queues.
Fabric Controller:
Tất cả các ứng dụng Windows Azure và dữ liệu Windows Azure Storage được lưu trữ trên các trung tâm dữ liệu – data center của Microsoft. Trong các trung tâm dữ liệu này, tập hợp các máy chủ dành riêng cho Microsoft được tổ chức thành một fabric.
Windows Azure Fabric bao gồm một nhóm lớn máy tính, tất cả được quản lý bởi phần mềm fabric controller. Fabric controller được sao lưu qua một nhóm từ 5-7 máy tính, và nó sở hữu tất cả các tài nguyên trong fabric: các máy tính, switch, các bộ câng bằng tải… Nó giao tiếp với một fabric agent trên mỗi máy tính, và vì vậy kiểm soát tất cả các ứng dụng Windows Azure trong fabric (điều thú vị là fabric controller coi Windows Azure Storage là một ứng dụng, vì vậy nó không biết thông tin chi tiết về việc quản lý và sao lưu dữ liệu)
Fabric controller giám sát tất cả các ứng dụng đang chạy, quản lý các hệ điều hành, chịu trách nhiệm các công việc như cập nhật bản vá lỗi cho Windows Server chạy các máy ảo Windows Azure. Nó cũng quyết định nơi các ứng dụng mới chạy, chọn các server vật lý để tối ưu hoá việc sử dụng phần cứng.
Để thực hiện điều này, fabric controller phụ thuộc vào một file cấu hình được upload cùng với mỗi ứng dụng Windows Azure. File này cung cấp một mô tả dựa trên
XMl những gì mà ứng dụng cần: bao nhiêu instance Web role, bao nhiêu instance Woker role,…Khi fabric controller nhận một ứng dụng mới, nó sử dụng file cấu hình này để xác định cần tạo bao nhiêu máy ảo Web role và Woker role.
Một khi đã tạo các máy ảo này, fabric controller chịu trách nhiệm giám sát chúng. Ví dụ, nếu một ứng dụng yêu cầu 5 web role instance và một trong số chúng bị lỗi, fabric controller sẽ tự động khởi tạo một instance mới.
Trong phiên bản hiện thời, Fabric controller cung cấp 4 loại máy ảo dưới đây. (Nhà phát triển có thể chọn loại máy ảo khi xây dựng ứng dụng thông qua Visual Studio)
- Small, CPU 1 nhân 1.6 GHz, 1.75 GB RAM, và 225 GB lưu trữ
- Medium, CPU 2 nhân 1.6Ghz, 3.5GB RAM, 490GB lưu trữ
- Larg, CPU 4 nhân 1.6Ghz, 7GB RAM, 1000GB lưu trữ
- Extra large, CPU 8 nhân 1.6Ghz, 14GB RAM, 2040GB lưu trữ
2.1.2 Storage Service
Windows Azure Storage service cho phép người dùng lưu trữ dữ liệu của ứng dụng trên cloud và truy cập đến nó từ bất kì đâu, bất kì lúc nào. Kiến trúc mở của dịch vụ lưu trữ cho phép nhà phát triển thiết kế ứng dụng và dịch vụ để lưu trữ và lấy dữ liệu sử dụng REST APIs. Mỗi kiểu lưu trữ trong dịch vụ Storage có một API lập trình REST độc lập. Hình dưới đây minh họa kiến trúc của dịch vụ lưu trữ:
Hình 2.6: Kiến trúc của Windows Azure Storage
Như hình trên, có thể thấy các kiểu lưu trữ đều có phạm vi ở cấp độ tài khoản. điều này có nghĩa khi người dùng mở một tài khoản lưu trữ, họ có thể truy cập đến tất cả các dịch vụ lưu trữ của Windows Azure.
Blob Service:
Dịch vụ blob được thiết kế để lưu trữ các đối tượng dạng nhị phân lớn, vớ các siêu dữ liệu kết hợp như tài liệu, ảnh, video, và file âm thanh. Nhờ việc lưu trữ các blob ít nhất 3 lần và phân phối chung qua nhiều server, dịch vụ blob cung cấp khả năng lưu trữ co giãn và có độ sẵn sàng cao. Nó cung cấp một API REST để lưu trữ các file đã được đặt tên cùng với siêu dữ liệu của chúng. REST API của blob cung cấp tính năng kiểm tra độ thống nhất cho các thao tác đồng thời – concurrent operations.
- Kích thước tối đa của mỗi block blob là 200GB và mỗi page blob là 1TB (có thể thay đổi trong tương lai)
- Có thể upload blob với kích thước bé hơn 64MB bằng một lệnh PUT đơn. Blob có
kích thước lớn hơn 64Gb phải upload dưới dạng tập hợp block, với mỗi block có kích thước không quá 4MB
- Dịch vụ Blob dành cho việc phát triển hỗ trợ kích thước blob tối đa 2GB. Kiến trúc của dịch vụ Blob:
Một container là một nhóm logic chứa một tập hợp blob. Container có thể chứa siêu dữ liệu dưới dạng cặp tên-giá trị. Có 2 kiểu container: kiểu public có thể được nhìn thấy bởi tất cả các user (Anomynous) cho mục đích chỉ đọc (read-only) mà không cần xác thực, và kiểu private, chỉ chủ của tài khoản mới có quyền truy cập. Blob là kiểu lưu trữ duy nhất hỗ trợ truy cập theo chế độ public và private, kiểu dữ liệu queue và table chỉ hỗ trợ kiểu truy cập private.
Có thể truy cập đến một container bằng URI dưới đây:
<http|https>://<account name>.blob.core.windows.net/<container> (adsbygoogle = window.adsbygoogle || []).push({});
Trong đó <container> là tên của container cần truy cập. Tển của container phải đảm bảo các ràng buộc dưới đây:
- Tên của container phải là duy nhất trong một tài khoản
- Tên của container phải bắt đầu bằng một chữ số hoặc một chữ cái.
- Tên của container không được chứa kí tự đặc biệt nào ngoại trừ dấu gạch nối (-)
- Dấu gạch nối phải được theo sau bằng một chữ số hoặc chữ cái
- Tất cả các chữ cái trong tên phải là chữ thường
- Tên không được ít hơn 3 và nhiều hơn 63 chữ cái
Nếu tên của container hoặc URI vi phạm các quy tắc đặt tên, một mã trạng thái HTTP 400 (Bad request) sẽ được trả về từ server.
Blobs:
Blobs, các thực thể thực sự của dịch vụ Blob, được lưu trữ trong các container. Tên một blob phải là duy nhất trong phạm vi container chứa nó. Một Blob có thể chứa siêu dữ liệu dưới dạng các cặp tên – giá trị. Access Control List chỉ được thiết lập ở cấp độ container, chính vì vậy, một container được set là public thì tất cả các blob trong nó đều là public. Có thể truy cập một blob sử dụng URI dưới đây:
<http|https>://<accountname>.blob.core.windows.net/<container>/<blob>
Trong đó <blob> là tên duy nhất của blob trong container. Ví dụ, có thể tạo một blob có tên 201004301212-logs trong một container tên Logs, có thể truy cập đến nó thông qua URI sau:
<http|https>://delta76.blob.core.windows.net/logs/201004301212-logs.txt
Tên một blob không thể dài hơn 1024 kí tự. Blob không hỗ trợ tạo cấu trúc thư mục để lưu trữ files, chỉ có thể lưu trữ file theo một cấu trúc “phẳng”. Trong phần lớn các ứng dụng, cấu trúc thư mục của file rất quan trọng cho việc truy cập dễ dàng. Để đơn giản hóa
việc tạo cấu trúc thư mục ảo, có thể thêm một dấu ngăn cách vào tên file. Ví dụ, có thể đặt tên một blob là 2010/04/30/1212-logs.txt. Với lược đồ tên này, có thể thêm nhiều file vào cấu trúc thư mục ảo 2010/04/30.
Blog API cung cấp khả năng lọc dựa trên dấu ngăn cách cho phép người dùng nhận về chỉ các file trong cấu trúc ảo cụ thể. Ví dụ, có thể chỉ nhận các file log trong ngày 30/4 bằng cách chỉ rõ một dấu phân cách (delimiter) khi truy vấn các blob.
Các kiểu blob:
Page blob:
Page Blob được giới thiệu trong phiên bản ngày 19/09/2009 của API cho dịch vụ lưu trữ. Chúng được tối ưu hóa cho việc truy cập đọc/ghi tuần tự và cung cấp khả năng copy một chuỗi byte thành một blob. Một page được đại diện bằng offset bắt đầu của nó tính từ vị trí bắt đầu của blob. Ghi vào các page blob sẽ ngay lập tức có hiệu lực đối với dịch vụ blob. Mỗi page có kích thước tối đa lên đến 1TB, và page blob tối ưu hóa cho các ứng dụng yêu cầu truy xuất đọc/ghi nhanh tới các dữ liệu dạng nhị phân như ảnh, video, tài liệu,… Windows Azure Storage Client API cung cấp 2 thao tác trên page block: Put Page và Get Page
Block Blob.
Như đã nói ở trên, nếu một file có kích thước lớn hơn 64MB, nó không thể upload lên dịch vụ Blob sử dụng hàm PUT Blob. Phải chia blob này ra thành nhiều blocks liên tiếp nhau và sau đó upload nó dưới dạng các mảnh dữ liệu nhỏ hơn – blosck. Mỗi Block có thể có kích thước tối đa 4MB. Một khi tất cả các block đã được upload lên, chúng có thể được chuyển thành blob. Cần chú rằng không có URI nào để truy cập các block trong một blob, sau khi các block đã được chuyển thành blob thì chỉ có thể nhận một blob hoàn chỉnh. Nói cách khác, chỉ có thể thực hiện thao tác GET ở cấp độ blob.
Upload và commit các block là 2 thao tác riêng biệt. Có thể upload các block theo bất cứ thứ tự nào, cũng có thể upload nhiều block đồng thời theo thứ tự ngẫu nhiên,
Hình 2.8: Minh hoạ về việc upload và commit các Block Các thao tác REST đối với block
Mỗi block được định danh bằng một Block ID, kích thước tối đa 64 byte, và có phạm vi trong tên blob. Vì vậy các blob khác nhau có thể có các block với cùng ID. Block là không thể thay đổi – immutable. Mỗi block có kích thước tối đa 4MB, và các block trong