Windows Azure

Window® Azure là một hệ điều hành các dịch vụ đám mây phục vụ như môi trường phát triển, dịch vụ, lưu trữ và quản lý dịch vụ cho Azure Service Platform. Window Azure cung cấp cho các các nhà phát triển với khả năng lưu trữ và tính toán theo yêu cầu để lưu trữ, mở rộng và quản lý Internet hay các ứng dụng đám mây. Window Azure hỗ trợ sự triển khai thí nghiệm phát triển thống nhất thông qua sự tích hợp của nó với Visual Studio. Trong phiên bản chạy miễn phí, .NET quản lý các ứng dụng xây dựng sử dụng Visual Studio sẽ được hỗ trợ. Window Azure là một nền tảng mở sẽ hỗ trợ cả các ngôn ngữ và môi trường của Microsoft và không phải của Microsoft. Window Azure mong muốn chào đón các công cụ của các bên thứ 3 và các ngôn ngữ như là Eclipse, Ruby, PHP, và Python.

2.1

[5]

.

- –

.)

.

. .

[2].

 Ứng dụng trên Windows Azure

Trên Windows Azure, một ứng dụng thông thường có nhiều thể hiện, mỗi cái chạy trên một bản sao của mã ứng dụng. Mỗi một thể hiện chạy trên máy ảo của riêng nó. Những máy ảo này chạy hệ điều hành Windows Server 2008 64 bit, và chúng cung cấp một mặt nạ (hypervisor) được thiết kế đặc biệt cho việc sử dụng trên đám mây.

Một nhà phát triển không cung cấp ảnh VM của riêng họ cho Windows Azure để chạy, hay không cần lo lắng về việc duy trì một bản sao hệ điều hành Windows.

Thay vào đó, phiên bản miễn phí cho phép nhà phát triển tạo ứng dụng sử dụng thể hiện Web role và/ hoặc Worker role. Hình 5 chỉ ra làm hai thể hiện trên.

Hình 2.2: Ứng dụng Windows Azure có thể bao gồm các thể hiện web role và worker role, trong đó mỗi thể hiện chạy trên máy ảo của riêng nó [6]

Như tên mô tả của nó, mỗi thể hiện web role chấp nhận các yêu cầu HTTP (hay HTTPS) đầu vào thông qua IIS (Internet Information Service) 7. Một Web Role có thể được cài đặt sử dụng ASP.NET, WCF hay một kĩ thuật khác mà làm việc với IIS. Như hình trên đã chỉ ra, Windows Azure cung cấp cơ chế cân bằng tải trọng để phân bổ các yêu cầu tới các thể hiện web role mà là các thành phần của cùng ứng dụng.

Một thể hiện worker role, ngược lại, không thể nhận yêu cầu trực tiếp từ bên ngoài – nó không được phép có bất kì đầu vào kết nối trên mạng nào, và IIS không chạy trong VM của nó. Thay vào đó, nó nhận đầu vào thông qua một hàng đợi trong nơi lưu trữ Windows Azure. Các thông điệp trong hàng đợi có thể đến từ thể hiện web role, một ứng dụng trong nhà hay một cái khác. Bất kể thông điệp đến từ đâu, một thể hiện worker role có thể gửi đầu ra tới hàng đợi khác hay ra bên ngoài – các kết nối đầu ra tới mạng bên ngoài được cho phép. Và không giống thể hiện web role, được tạo ra để điều khiển các yêu cầu HTTP đầu vào, một thể hiện worker role là một công việc theo lô. Thích hợp với số đông, một worker role có thể được cài đặt sử dụng bất kì kĩ thuật Windows nào với một phương thức main().

Kể cả chạy thể hiện web role hay worker role, mỗi VM chứa một tác nhân Windows Azure (Windows Azure agent) cho phép ứng dụng tương tác với Windows Azure fabric, như hình trên chỉ ra. Agent đưa ra một API cho phép thể hiện ghi vào một log được duy trì bởi Windows Azure, gửi các cảnh báo tới chủ ứng dụng thông qua Windows Azure fabric, và nhiều công việc khác nữa.

Phiên bản Windows Azure đầu tiên duy trì một quan hệ một - một giữa VM và một nhân bộ xử lý – và do đó hiệu năng của mỗi ứng dụng có thể được đảm bảo. Mỗi thể hiện web role và Worker role có nhân xử lý của riêng nó. Để tăng hiệu năng của ứng dụng, chủ sở hữu ứng dụng có thể tăng số lượng thể hiện chạy trong file cấu hình của ứng dụng. Windows Azure fabric sẽ khởi tạo VM mới, đăng ký nó với các bộ xử lý, và bắt đầu chạy thêm các thể hiện của ứng dụng. Fabric cũng phát hiện khi nào một Web role hoặc Worker role bị lỗi, và khởi tạo một cái mới. Cả các Web Role và Worker Role được cài đặt sử dụng kĩ thuật chuẩn Windows. Tuy nhiên việc chuyển đổi từ ứng dụng đã tồn tại sang Windows Azure vẫn đòi chút tay đổi. Trong Windows Azure, truy cập nơi lưu trữ của Windows Azure sử dụng các dịch vụ dữ liệu ADO.NET không có trong các ứng dụng trên máy cục bộ trước đây (một ứng dụng Windows Azure có thể sử dụng ADO.NET chuẩn để truy cập nơi lưu trữ quan hệ cung cấp bởi Cơ sở dữ liệu SQL Azure, do đó tạo điều kiện dễ dàng để chuyển một ứng dụng đã tồn tại lên nền tảng đám mây.) Hơn nữa, các thể hiện worker role dựa trên những hàng đợi trong Windows Azure storage cho đầu vào của chúng. Đây một sự ảo hóa không có sẵn trong các môi trường Windows trong nhà. Tuy nhiên, nhìn chung một ứng dụng chạy trên Windows Azure sẽ trông giống như nó chạy trên bất kì hệ thống Windows server 2008 nào. Đối với các nhà phát triển, xây dựng một ứng dụng Windows Azure trong phiên bản miễn phí giống như xây dựng một ứng dụng Windows truyền thống. Microsoft cung cấp các mẫu project trong Visual Studio 2008 cho việc tạo các Windows Azure web role, worker role, và sự tổ hợp của chúng. Các nhà phát triển được tự do sử dụng các ngôn ngữ lập trình Windows (mặc dù công bằng mà nói Microsoft tập trung chính vào ngôn ngữ C#). Hơn nữa, bộ phát triển phần mềm Windows Azure bao gồm một phiên bản của môi trường Windows Azure chạy trên máy của nhà phát triển. được biết như Windows Azure Development Fabric, nó bao gồm Windows Azure storage, một tác nhân Windows Azure, và mọi thứ khác liên quan đến việc chạy ứng dụng trên đám mây. Một nhà phát triển có thể tạo và gỡ lỗi ứng dụng của họ sử dụng sự mô phỏng trên máy cục bộ, sau đó phân phối ứng dụng tới Windows Azure trong đám mây khi đã sẵn sàng. Tuy vậy, có một số thứ khác biệt

khi đưa lên đám mây. Ví dụ, không thể ghép một bộ gỡ lỗi lên ứng dụng dựa trên đám mây, và do đó việc gỡ lỗi ứng dụng trên đám mây dựa trên việc viết vào log được duy trì bởi Windows Azure thông qua tác nhân Windows Azure.

 Lưu trữ dữ liệu: Các ứng dụng làm việc với dữ liệu theo nhiều cách khác nhau. Thỉnh thoảng, chúng chỉ yêu cầu các blob, trong khi lúc khác lại cần những cấu trúc phức tạp hơn để lưu trữ dữ liệu. Và trong một số trường hợp, cần một cách để trao đổi dữ liệu giữa những phần khác nhau của một ứng dụng. Windows Azure storage tập trung vào những yêu cầu như đã nêu trên, như được chỉ ra ở hình 2.3.

Hình 2.3: Windows Azure cho phép lưu trữ dữ liệu trong các blob, table, và queue, sử dụng RESTful để truy cập[6]

Cách đơn giản nhất để lưu trữ dữ liệu trong Windows Azure storage là sử dụng blob[6]. Như hình trên chỉ ra, có một sự phân cấp đơn giản: một tài khoản lưu trữ (storage account) có thể có một hay nhiều container, mỗi một container lại chứa một hay nhiều các blob. Blob có thể lớn lên tới tận 50 gigabytes, và để làm cho việc vận chuyển những blob lớn dễ dàng hiệu quả, mỗi một blob có thể được phân chia thành những khối nhỏ. Nếu một lỗi xảy ra, sự vận chuyển lại được khôi phục

với những khối gần nhất chứ không phải với toàn bọ blob. Các blob có thể có siêu dữ liệu đi kèm, như là thông tin về nơi lưu trữ ảnh JPEG hay ai là tác giả file MP3. Blob là một kiểu dữ liệu, nhưng chúng không có cấu trúc. Để cho phép ứng dụng làm việc với dữ liệu theo cách hiệu quả hơn, Windows Azure storage cung cấp các bảng [10]. Chúng không phải là các bảng quan hệ. Thực chất, mặc dù chúng được gọi là các bảng, dữ liệu chúng lưu trữ thực chất được đặt trong một tập các thực thể với các thuộc tính. Một bảng không có lược đồ định nghĩa. Thay vào đó, các thuộc tính có thể có nhiều kiểu khác nhau, như là int, string, bool, hay datatime. Một ứng dụng có thể truy cập dữ liệu của bảng sử dụng dịch vụ dữ liệu ADO.NET hay LINQ. Một bảng đơn có thể là rất lớn, với hàng tỉ các thực thể và kích thức hàng terabyte dữ liệu, và Windows Azure storage có thể phân chia và đặt nó trên nhiều server nếu cần thiết để cải thể thiện hiệu năng.

Các blob và bảng chủ yếu để lưu trữ dữ liệu. Lựa chọn thứ 3 trong Windows Azure storage là hàng đợi (queue), có mục đích hoàn toàn khác. Vai trò chính của hàng đợi là cung cấp một cách để các thể hiện Web role liên lạc với thể hiện Worker role. Ví dụ, một người dùng có thể gửi một yêu cầu tới thực hiện một số công việc liên quan tới tính toán thông qua trang web cài đặt bởi một Windows Azure Web role. Thể hiện Web role nhận được yêu cầu này có thể viết một message vào một hàng đợi mô tả công việc được làm. Một thể hiện Worker role mà đang đợi hàng đợi này có thể đọc message và thực hiện công việc. Kết quả nào có thể được trả lại thông qua một hàng đợi khác hay được điều khiển theo một cách khác.

Không quan tâm đến việc nó được lưu trữ như thế nào – trong blob, table, hay hàng đợi – mọi dữ liệu trong Windows Azure storage được sao lưu làm 3 bản. Sự sao lưu này cho phép chống chịu lỗi, do có thể bị mất một bản sao lưu. Hệ thống đảm bảo sự thống nhất, do đó một ứng dụng mà đọc dữ liệu nó đã từng ghi vào sẽ lấy được những gì nó mong muốn.

Windows Azure storage có thể được truy cập bằng một ứng dụng Windows Azure hay bằng một ứng dụng chạy ở một nơi nào đó. Trong cả hai trường hợp, ba kiểu lưu trữ của Windows Azure sử dụng quy định của REST để xác định và đưa ra dữ liệu. Mọi thứ được đặt tên sử dụng URIs và truy cập với thông qua HTTP chuẩn. Một client .NET có thể sử dụng ADO.NET Data Service và LINQ, nhưng truy cập Windows Azure storage từ một ứng dụng Java chỉ có thể sử dụng RESTful. Ví dụ, một blob có thể được đọc với một HTTP GET dựa trên một URI như sau:

<StorageAccount> là một định danh được gán khi một tài khoản lưu trữ được tạo ra, và nó xác định một tập blob, table, hàng đợi duy nhất. được tạo ra khi sử dụng tài khoản này. <Container> và <BlobName> chỉ là tên của container và blob cần yêu cầu truy cập.Tương tự như vậy, một truy vấn trên một table được mô tả như một HTTP GET dựa trên một URI như sau:

http://<StorageAccount>.table.core.windows.net/<TableName>?$filter=<Query> , <TableName> xác định bảng được truy vấn, trongkhi <Query> chứa truy vấn được thực hiện đối với bảng này. Thậm chí hàng đợi cũng được truy cập bởi cả ứng dụng Windows Azure và ứng dụng bên ngoài bằng cách sử dụng một HTTP GET dựa trên định dạng URI như sau:

http://<StorageAccount>.queue.core.windows.net/<QueueName>

Windows Azure platform tính phí độc lập cho việc tính toán và lưu trữ tài nguyên. Điều đó có nghĩa rằng một ứng dụng trong nhà có thể chỉ sử dụng Windows Azure storage, truy cập dữ liệu của nó theo cách RESTful mô tả ở trên. Và bởi vì dữ liệu đó có thể được truy cập trực tiếp từ ứng dụng không phải Windows Azure, nó có thể vấn hoạt động thậm chí khi ứng dụng Windows Azure sử dụng nó không chạy.