Đề tài Xây dựng hệ thống quản trị nội dung sử dụng Windows Azure Platform

ác máy tính tại Microsoft Data Center và có thể truy cập thông qua Internet. Hình 2.3 mô tả các thành phần chính của Windows Azure: Compute, Storage và Fabric. Hình 2.3: Các thành phần Windows Azure [4] Windows Azure Fabric đảm nhiệm kết nối hệ thống máy này thành một sức mạnh tính toán thống nhất, các dịch vụ Compute và Storage sẽ được xây dựng dựa trên Fabric. Compute service đảm nhiệm thực thi các ứng dụng, trong khi Storage service lưu trữ dữ liệu. Windows Azure Fabric cung cấp phương thức để quản lý, giám sát các ứng dụng chạy trên platform. 2.2.1.1 Dịch vụ Compute Dịch vụ Windows Azure Compute cung cấp khả năng thực thi các ứng dụng/dịch vụ đám mây. Compute service cho phép bạn chạy các ứng dụng trên các máy ảo Windows Server đặt tại Microsoft Datacenter. Do mục đích chính của Windows Azure là hỗ trợ các ứng dụng có thể phục vụ rất nhiều người cùng lúc, Windows Azure giải quyết vấn đề này bằng cách chạy nhiều phiên bản của cùng một code ứng dụng trên nhiều server khác nhau, mỗi phiên bản gọi là một thể hiện (instance). Các ứng dụng Windows Azure có thể có nhiều instances, mỗi một instance thực thi trong máy ảo riêng (Virtual Machine –VM). Các VM này chạy hệ điều hành Windows Server 2008 64-bit với cơ chế hypervisor được thiết kế phù hợp với môi trường Cloud, có cài đặt Internet Information Services (IIS) 7. Để chạy ứng dụng, developer truy cập Windows Azure portal từ Web browser, đăng nhập bằng tài khoản Windows Live ID, sau đó lựa chọn tạo hosting account để thực thi ứng dụng hay storage account để lưu trữ dữ liệu hay cả hai. Một khi đã có hosting account, developer có thể upload ứng dụng, xác định số lượng instances, xác định số lượng instances mà ứng dụng cần. Windows Azure sẽ tạo ra các máy ảo cần thiết và chạy ứng dụng. Ở phiên bản khởi đầu của Windows Azure, Community Technology Preview (CTP), 2 loại instance có thể được sử dụng: Web Role instance và Worker Role instance. Hình 2.4: WebRole và WorkerRole instances trong khối Compute [3] Web Role instance có thể chấp nhận các yêu cầu HTTP hay HTTPS. Nó chạy trong các VM có cài đặt Internet Information Service (IIS) 7. Developers có thể tạo Web Role instance sử dụng ASP.NET, WCF hoặc các công nghệ .NET khác tương thích với IIS. Khi thực thi, các yêu cầu HTTP, HTTPS sẽ đi qua bộ chia tải (Load Balancer) để đến được với các WebRole instances của ứng dụng. Bằng việc sử dụng nhiều instance và load balancer , Windows Azure giúp cho ứng dụng có thể co giãn tăng giảm quy mô. Khác với Web Role, Worker Role không thể nhận các yêu cầu trực tiếp từ bên ngoài, Worker Role lấy các input thông qua hàng đợi (Queue) trong Windows Azure Storage. Các thông điệp trong queue này có thể đến từ Web Role, từ ứng dụng on-premises. Virtual Machine chạy Worker Role không chạy IIS. Worker Role sau đó có thể gửi output ra một queue khác hoặc ra bên ngoài (có thể mở kết nối ra bên ngoài). Không giống như Web Role instance dùng để xử lý các HTTP Request, Worker Role instance xử lý theo lô (batch job). Cho dù Virtual Machine chạy Web Role instance hay Worker Role instance, mỗi VM đều có chứa một Windows Azure Agent cho phép ứng dụng tương tác Windows Azure Fabric. Chẳng hạn một instance có thể sử dụng agent để ghi vào Windows Azure log, gửi thông báo thông qua Fabric. Cả Web Role instance và Worker Role intance đều có thể truy xuất hệ thống file trên VM mà nó thực thi, tuy nhiên lưu ý rằng hệ thống lưu trữ file này không có tính bền vững, nghĩa là nếu như instance đó bị loại bỏ (shutdown) thì VM và toàn bộ dữ liệu trên VM đó cũng bị xóa bỏ. Do vậy để lưu trữ dữ liệu đảm bảo tính bền vững (dữ liệu tồn tại ngay cả khi ứng dụng bị xóa bỏ hay không hoạt động) ta cần một không gian lưu trữ khác, đó chính là mục đích của dịch vụ Windows Azure Storage. 2.2.1.2 Dịch vụ Storage Ứng dụng có thể làm việc, thao tác dữ liệu theo nhiều cách khác nhau, dịch vụ Windows Azure Storage cung cấp các phương thức lưu trữ và xử lý dữ liệu. Để làm việc với Storage, việc đầu tiên là phải tạo một tài khoản Storage (Storage Account), Windows Azure sẽ cung cấp một khóa bí mật cho tài khoản để kiểm soát các truy nhập vào thông tin trong tài khoản Storage đó, mỗi ứng dụng muốn truy xuất dữ liệu (blobs, table hoặc queue) từ Storage phải cung cấp khóa bí mật để xác thực. Hình 2.5 mô tả các dịch vụ lưu trữ trong Storage service: Blobs, Tables và Queues Hình 2.5: Các dịch vụ Storage Services [3] Blobs Cách thông thường nhất để lưu trữ dữ liệu là sử dụng Blobs (Binary-large-objects). Blobs có thể chứa hình ảnh, âm thanh, video, emails,... Để làm việc với Blobs, lập trình viên phải tạo ít nhất một vùng chứa (containers) trong storage account, mỗi một vùng chứa này sẽ chứa một hoặc nhiều blobs. Blobs có thể rất lớn, kích thước tối đa là 50 gigabytes. Để xác định một blobs cụ thể, ứng dụng sử dụng chuỗi URI có dạng: Trong đó là định danh khi tạo tài khoản Storage, và là tên Container và tên Blob cần truy xuất. Lưu ý là các Container chỉ có thể chứa Blobs, không thể lồng ghép Container khác nên việc tạo cấu trúc phân cấp với Container là không thể. Thay vào đó, có thể dùng ký hiệu “/” trong tên Blob (BlobName) để phân cấp nếu cần. Như đã nói kích thước Blobs có thể lên tới 50GB, nên để việc truyền dữ liệu Blobs hiệu quả, mỗi blobs có thể được chia ra thành nhiều khối (block), nếu việc truyền bị ngắt quãng, có thể truyền lại bắt đầu từ khối được truyền gần nhất thay vì phải truyền lại cả blobs, sau khi tất cả các block được truyền, chúng sẽ được ghép lại thành blobs ban đầu. Có thể quy định thuộc tính private (riêng tư) hoặc public (công cộng) cho Container, với các blobs trong private container, các yêu cầu đọc và ghi cần được xác thực với khóa bí mật tương ứng của Storage Account chứa blobs, trong khi với public container, chỉ thao tác ghi cần cung cấp khóa bí mật, mọi ứng dụng có thể đọc dữ liệu từ public container. Tables Để làm việc với các dữ liệu có cấu trúc, Windows Azure storage cung cấp tables service. Trên thực tế đó không phải là các bảng quan hệ, dữ liệu chứa trong chúng thực tế là tập các thực thể với các thuộc tính. Thay vì sử dụng SQL ứng dụng truy cập các table sử dụng cú pháp định nghĩa bởi ADO.NET Data Services. Mỗi một table chứa một hoặc nhiều thực thể, mỗi thực thể lại có các thuộc tính, các thuộc tính gồm 3 thành phần: Tên thuộc tính (name), kiểu thuộc tính (type) và giá trị thuộc tính (value). Có rất nhiều kiểu thuộc tính được hỗ trợ, gồm Binary, Bool, DateTime, Double, GUID, Int, Int64, String. Mỗi một thuộc tính còn có thể có kiểu khác nhau vào những thời điểm khác nhau tùy thuộc vào giá trị lưu trong nó, hơn nữa cũng không cần thiết tất cả các thuộc tính trong 1 thực thể phải có cùng kiểu. Kích thước tối đa của một thực thể là 1MB và mỗi thực thực được coi là đơn vị dữ liệu, thao tác đọc một thực thể sẽ trả lại giá trị của tất cả các thuộc tính. Ngược lại thao tác ghi sẽ thực hiện ghi lên tất cả các thuộc tính. Windows Azure Tables Storage có nhiều điểm khác biệt với các bảng dữ liệu quan hệ, đầu tiên là chúng thực sự không phải là các bảng thông thường, không thể truy cập sử dụng thuần túy ADO.NET hay truy vấn SQL. Tables Storage không quy định cấu trúc (schema) chặt chẽ như bảng quan hệ, một thuộc tính trong mỗi thực thể có thể có kiểu dữ liệu khác nhau và có thể thay đổi. Một câu hỏi được đặt ra: Tại sao Windows Azure không hỗ trợ mô hình các bảng dữ liệu quan hệ trong Tables và khả năng truy vấn SQL như các hệ RDBMS thông thường? Câu trả lời cũng nằm ở mục tiêu hỗ trợ khả năng mở rộng mạnh mẽ cho ứng dụng. Các bảng quan hệ truyền thống có thể scale-up, phục vụ số lượng lớn người dùng bằng việc chạy DBMS trên các máy chủ cực mạnh. Tuy nhiên để thực sự hỗ trợ số lượng khổng lồ yêu cầu cùng một lúc, không gian lưu trữ cần scale-out chứ không chỉ scale-up, đó là lý do Windows Azure Storage thiết kế mô hình thực thể trong Tables thay vì các bảng dữ liệu quan hệ với chuẩn SQL thông thường. Ứng dụng .NET có thể truy cập vào các tables bằng cách sử dụng ADO.NET Data Services hoặc Language Integrated Query (LINQ), chẳng hạn một yêu cầu HTTP GET để truy vấn tables sẽ có dạng: Ở đây chỉ ra tên bảng cần truy vấn, chứa câu lệnh truy vấn theo chuẩn LINQ. Việc cập nhật dữ liệu vào tables có thể gặp vấn đề: Điều gì xảy ra nếu hai ứng dụng cùng muốn cập nhật dữ liệu vào 1 thực thể trong table, việc cập nhật một thực thể sẽ bao gồm đọc thực thể, thay đổi nội dung thuộc tính, thêm/xóa thuộc tính và ghi lại thực thể vào bảng. Giả sử cả 2 ứng dụng đều cùng đọc thực thể, chỉnh sửa và sau đó ghi lại, điều gì sẽ xảy ra? Câu trả lời là ứng dụng nào thực hiện ghi trước sẽ thành công, còn ứng dụng ghi sau sẽ thất bại. Queues Blob và Table Storage đều sử dụng để lưu trữ và truy xuất dữ liệu. Dạng lưu trữ thứ ba được Windows Azure cung cấp có mục đích hơi khác. Tính năng chính của queue là cung cấp phương thức để Web Role instance kết nối với Worker Role instance. Ví dụ, user submit một yêu cầu tính toán thông qua giao diện web, Web Role instance nhận request này và ghi một message vào queue mô tả công việc cần thực hiện. Worker Role instance có thể đọc message và xác định công việc cần thực thi. Các ứng dụng Windows Azure và các ứng dụng khác đều có thể tham chiếu đến một queue sử dụng URI có dạng: 2.2.1.3 Fabric Toàn bộ ứng dụng và dữ liệu trong Windows Azure Storage đều chứa trong các data center của Microsoft. Trong data center, hệ thống máy móc này được tổ chức thành các fabric. Hình 2.6: Fabric Controller [5] Windows Azure Fabric gồm một nhóm các máy tính, các máy trong nhóm đều được quản lý bởi một phần mềm gọi là fabric controller. Fabric Controller quản lý một nhóm từ 5 – 7 máy tính và sở hữu tất cả tài nguyên trong fabric: máy tính, switches, load balancers, … Fabric controller có khả năng giao tiếp với fabric agent trên các máy, nó cũng giám sát các ứng dụng Windows Azure trong fabric đó. Fabric controller giám sát các ứng dụng thực thi, quản lý operating system, đảm nhiệm các công việc như vá lỗi, cập nhật VM. Nó cũng quyết định ứng dụng sẽ chạy ở nơi nào, lựa chọn server vật lý để tối ưu hóa hệ thống phần cứng. Để làm điều đó fabric controller phụ thuộc vào file cấu hình được upload cùng với mỗi ứng dụng Windows Azure , file này có cấu trúc dạng XML mô tả những thông tin cấu hình mà ứng dụng cần: bao nhiêu Web Role instance, bao nhiêu Worker Role instance, …Khi fabric controller nhận được một ứng dụng mới, nó sẽ sử dụng file cấu hình này để xác định bao nhiêu Web Role và bao nhiêu Worker Role VM cần thiết lập. Một khi VM đã được tạo ra, fabric controller sẽ giám sát VM đó, nếu một ứng dụng yêu cầu 5 Web Role instances và một trong số đó gặp vấn đề trục trặc, Fabric Controller sẽ tự động khởi động lại một instance mới, hoặc nếu máy chủ mà VM chạy gặp vấn đề, fabric controller sẽ khởi động instance mới trên một VM mới (tất nhiên trên máy chủ khác) và thiết lập lại load balancer để trỏ đến máy chủ mới. 2.2.2 SQL Azure SQL Azure cung cấp tập các dịch vụ đám mây hỗ trợ lưu trữ và làm việc với nhiều loại thông tin. Hiện tại, Microsoft đưa ra 2 thành phần chính của SQL Azure: SQL Azure Database và “Huron” Data Sync. Hịnh 2.7: Các dịch vụ bên trong SQL Azure [4] 2.2.2.1 SQL Azure Database SQL Azure Database cung cấp một RDBMS trong “đám mây”. Nó cho phép ứng dụng đám mây và ứng dụng on-premises có thể lưu trữ cơ sở dữ liệu quan hệ hoặc dạng khác trên các server tại Microsoft Data Center. Chi phí sẽ được tính dựa trên những gì sử dụng, thay đổi tùy theo nhu cầu sử dụng. Sử dụng Cloud Database cũng cho phép người dùng không phải bận tâm đến các phần mềm DBMS, đĩa cứng lưu trữ, … Không giống như Windows Azure Storage service, SQL Azure Database xây dựng dựa trên Microsoft SQL Server. SQL Azure Database hỗ trợ cơ sở dữ liệu quan hệ, môi trường SQL Server trong Cloud với Indexes, Views, Store Procedures, Triggers, … Dữ liệu có thể truy cập thông qua ADO.NET và các giao diện truy cập dữ liệu khác của Windows. Trong khi các ứng dụng sử dụng SQL Azure Database hầu như tương tự như sử dụng local DBMS thì công sức quản lý CSDL giảm đi rất nhiều khi sử dụng SQL Azure Database. Người sử dụng SQL Azure Database có thể tập trung vào đối tượng quan tâm chính của họ: Dữ liệu. Hình 2.8: Cơ sở dữ liệu quan hệ SQL Azure Database [4] Ứng dụng sử dụng SQL Azure Database có thể chạy trên Windows Azure, trong Data Center của doanh nghiệp, trên thiết bị di động, … Ứng dụng truy cập dữ liệu thông qua giao thức Tabular Data Stream (TDS). Đó cũng là giao thức được sử dụng đê truy cập dữ liệu trong local SQL Server database. Nhờ đó ứng dụng chạy SQL Azure Database có thể sử dụng client library của SQL Server. Quan trọng nhất có lẽ là ADO.NET, ODBC và các thư viện khác cũng có thể sử dụng. Trong SQL Azure Database, tất cả dữ liệu được nhân bản (replicate) 3 lần, khi ghi dữ liệu (write), toàn bộ các bản sao được cập nhật. Mục đích là cung cấp tính tin cậy dữ liệu ngay cả trong trường hợp hệ thống bị lỗi. Kích thước tối đa của một CSDL trong SQL Azure Database là 10 gigabytes. Ứng dụng cần không gian dữ liệu lớn hơn có thể sử dụng nhiều database. 2.2.2.2 Huron Data Sync Thành phần thứ 2 trong SQL Azure được giới thiệu là “Huron” Data Sync, xây dựng dựa trên Microsoft Sync Framework và SQL Azure Database, công nghệ này cho phép đồng bộ dữ liệu thông qua các on-premises DBMS. Người sử dụng và sở hữu dữ liệu sẽ xác định những gì cần đồng bộ, giải quyết các xung đột như thế nào, … Hình 2.9: Đồng bộ dữ liệu giữa SQL Azure Database và các nguồn CSDL khác [4] 2.2.2.3 Ứng dụng SQL Azure Các ứng dụng có thể sử dụng SQL Azure theo nhiều cách đa dạng: Ứng dụng Windows Azure lưu trữ dữ liệu trong SQL Azure Database, mặc dù Windows Azure có hỗ trợ Storage service, tuy nhiên nó không hỗ trợ mô hình bảng quan hệ. Trong khi đó mô hình bảng quan hệ rất phổ biến, các ứng dụng có thể dễ dàng làm việc với CSDL. Các ứng dụng trong một doanh nghiệp nhỏ hoặc một phần trong doanh nghiệp lớn có thể lưu trữ dữ liệu trên SQL Azure Database thay vì local SQL Server hoặc Access. Ứng dụng có thể tận dụng được những ưu điểm về độ tin cậy và tính sãn sàng của Cloud Storage Một nhà sản xuất có thể đưa dữ liệu lên SQL Azure Database để có thể truy cập từ các ứng dụng của nhà phân phối hoặc từ ứng dụng web để khách hàng truy cập. Tạo bản sao database nhờ ứng dụng “Huron” Data Sync 2.2.3 AppFabric (.NET Service) AppFabric (tên cũ là .NET Services) cung cấp các dịch vụ cơ sở hạ tầng (Infrastructure) trên “đám mây”. AppFabric hỗ trợ các nhà phát triển kết nối các ứng dụng và dịch vụ trong các đám mây hoặc on-premise (tải về). Nó bao gồm các ứng dụng chạy trong môi trường Windows Azure, Windows Server và các nền tảng khác như Java, Ruby, PHP, … AppFabric bao gồm 2 dịch vụ: Service Bus và Access Control. Access Control: Access Control cho phép bạn xây dựng hệ thống xác thực và kiểm tra thẩm quyền cho ứng dụng / dịch vụ web của bạn, giảm thiểu sự phức tạp trong việc tích hợp với rât nhiều các công nghệ xác thực mà khách hàng đang sử dụng. Sử dụng mô hình đơn giản và quen thuộc, Access Control cho phép bạn định nghĩa các quy tắc và yêu cầu, các quy tắc này có thể cấu hình để phù hợp với ứng dụng. Hình 2.10: Access Control quy định quyền truy cập với Users và Applications [9] Service Bus: Service Bus cung cấp kết nối an toàn giữa các dịch vụ và ứng dụng, cho phép chúng có thể vượt qua các rào cản như tường lửa hay giới hạn mạng, nhờ đó giải quyết các khó khăn liên quan đến các ràng buộc trong hệ thống mạng của ứng dụng. Một khi Service Bus thiết lập kết nối giữa các ứng dụng, nó cho phép các ứng dụng có thể liên lạc với nhau một cách mềm dẻo. Nhà phát triển có thể xây dựng giải pháp theo nhiều mô hình truyền thông khác nhau như relay, buffer, bidirectional (2 chiều), publish-subcribe, multicast, streaming hay direct-connect (kết nối trực tiếp). ServiceBus cung cấp cho mỗi dịch vụ 1 địa chỉ URI ổn định có thể truy cập được từ bất kỳ ứng dụng nào được xác thực. Hình 2.11: Service Bus kết nối giữa các ứng dụng cloud và on-premise [9] 2.3. Các mô hình ứng dụng Windows Azure Phần 2.2 đã trình bày các thành phần và dịch vụ mà Windows Azure Platform hỗ trợ, tuy nhiên để có thể tận dụng sức mạnh của nền tảng này, các thành phần đó cần được phối hợp với nhau một cách hiệu quả và hợp lý. Phần này sẽ đưa ra 4 mô hình xây dựng ứng dụng dựa trên nền tảng Windows Azure. Bốn mô hình ứng dụng trên là những mục tiêu cơ bản của Windows Azure CTP, trong tương lai, Windows Azure còn tiếp tục phát triển và cung cấp những giải pháp ngày càng mạnh mẽ hơn. 2.3.1. Ứng dụng web có khả năng mở rộng Giả sử một tổ chức muốn tạo một ứng dụng web, cách thông thường là sẽ là chạy ứng dụng đó trên một máy chủ của tổ chức đó hoặc của một nhà cung cấp host. Tuy nhiên, trong nhiều trường hợp, sử dụng một nền tảng đám mây như Windows Azure sẽ là lựa chọn tốt hơn. Chằng hạn, nếu như ứng dụng web cần phục vụ một số lượng lớn người dùng đồng thời, việc xây dựng ứng dụng trên nền Windows Azure sẽ hỗ trợ thực sự cho ứng dụng có thể tùy chỉnh quy mô, co giãn (scale) ứng dụng và dữ liệu để chịu tải lớn tốt hơn nhiều so với các công nghệ web truyền thống. Hoặc trong trường hợp tải của ứng dụng có sự thay đổi đáng kể, có những khoảng thời gian ứng dụng chỉ chịu tải rất ít, nhưng có những thời điểm tăng cao bất ngờ. Các ứng dụng dạng này có thể tìm thấy chẳng hạn như các trang tin tức hoặc chia sẻ video, khi có những tin nóng hoặc những đoạn video có thể thu hút số lượng người truy cập tăng nhanh chóng mặt, hoặc trong khoảng thời gian 1 ngày, số lượng truy cập của ứng dụng chỉ tập trung vào 1 khoảng thời gian nhất định. Chạy các ứng dụng dạng này theo mô hình truyền thống luôn cần phải có đủ tài nguyên để đối phó trong mọi trường hợp ứng dụng chịu tải bất ngờ, ngay cả những thời điểm ứng dụng chỉ phục vụ khá ít truy cập. Nếu như ứng dụng được xây dựng trong môi trường Windows Azure, người hay tổ chức sở hữu ứng dụng có thể mở rộng hay thu hẹp quy mô ứng dụng bằng cách thay đổi số lượng instance cấp cho ứng dụng tùy theo tình huống, Windows Azure sẽ tính chi phí trên số lượng instance mà ứng dụng dùng đến, nhờ đó tiết kiệm được tài nguyên so với cách host truyền thống. Để tạo ứng dụng web có khả năng mở rộng, nhà phát triển có thể sử dụng Web Role và Tables Storage. Hình 2.12 mô tả một khung ứng dụng cơ bản sử dụng Web role và Tables Hình 2.12: Mô hình ứng dụng web có khả năng mở rộng [5] Trong mô hình trên, ứng dụng có thể được xây dựng dựa trên nền ASP.NET hoặc 1 công nghệ Web khác. Nhà phát triển cũng có thể tạo ứng dụng web có khả năng mở rộng bằng cách sử dụng WCF với dịch vụ mạng (Web Services) RESTful hoặc dịch vụ mạng dựa trên SOAP (SOAP-base). Trong mọi trường hợp, nhà phát triển có thể chỉ định số lương instances ứng dụng sử dụng, Windows Azure Fabric Controller sẽ tạo ra các VM tương ứng. Như đã đề cập ở phần 2.2.1.3 (Fabric), fabric controller sẽ giám sát các instances, đảm bảo ứng dụng luôn có đủ số instance phục vụ cho ứng dụng. Để lưu trữ dữ liệu, ứng dụng sử dụng Windows Azure Storage Tables với khả năng scale-out để lưu trữ số lượng lớn dữ liệu. 2.3.2. Ứng dụng xử lý song song: Một trường hợp ứng dụng khác của Windows Azure là tạo các ứng dụng xử lý song song. Nhiều tổ chức/cơ quan đôi khi cần một số lương lớn các máy tính để xử lý 1 chương trình song song, chẳng hạn như để render các hiệu ứng đặc biệt cho một bộ phim, xử lý nghiệp vụ trong một ngân hàng, …Một giải phát là có thể đầu tư một hệ thống tính toán song song (cluster) gồm nhiều máy với cấu hình mạnh, tuy nhiên chi phí sẽ rất cao. Windows Azure sẽ là giải pháp kinh tế hơn nhiều, gần như một giải pháp siêu máy tính trực tuyến theo yêu cầu (on-demand SuperComputer). Nhà phát triển có thể sử dụng Worker Role để tạo các ứng dụng dạng này, hơn nữa, các ứng dụng song song thường sử dụng đến không gian dữ liệu lớn, Windows Azure có thể đáp ứng bằng Blobs. Hình 2.13 mô tả một khung ứng dụng song song trên nền Windows Azure Hình 2.13: Mô hình ứng dụng song song sử dụng WebRole, nhiều Worker Role instances, queues và blobs [5] Trong mô hình trên, việc tính toán song song được thực hiện bởi một số lượng lớn các Worker Role chạy song song, các Worker Role này sử dụng Blobs để lưu trữ dữ liệu. Để tương tác với ứng dụng, người dùng thống qua 1 WebRole instance, từ giao diện tương tác này, người dùng có thể xác định số lượng Worker Role instance cần thiết, khởi động, tạm dừng 1 số instance, lấy kết quả, … Việc liên lạc giữa WebRole instance và Worker Role instance được thực hiện nhờ “cầu nối” Queues Storage. Các queues này có thể truy cập từ các ứng dụng on-premise, do đó nếu không muốn phụ thuộc vào Web Role instance của Windows Azure, nhà phát triển có thể xây dựng ứng dụng chạy từ máy local để tương tác với các Worker Role instances. Hình 2.14 mô tả một tình huống như vậy Hình 2.14: Mô hình ứng dụng song song kết nối từ ứng dụng cục bộ đến Worker Role [5] Trong mô hình này, việc xử lý song song vẫn được thực hiện trên các Worker Role instances chạy song song, mỗi một instance tương tác với bên ngoài thông qua Queues, tuy nhiên khác với mô hình trước đó, lúc này các công việc trong Queues sẽ được ghi trực tiếp từ ứng dụng on-premises. 2.3.3. Ứng dụng web có khả năng mở rộng với xử lý hậu cảnh Có thể nói rằng ngày nay, rất nhiều ứng dụng đã được phát triển theo mô hình web-based, người sử dụng có thể tương tác thông qua trình duyệt. Việc giao tiếp ứng dụng thông qua trình duyệt có thể nói là đem lại nhiều thuận tiện và linh hoạt, tuy nhiên chúng cũng có những hạn chế. Có rất nhiều tình huống khi ứng dụng web-base cũng cần khởi tạo các công việc chạy ở hậu cảnh (background), độc lập với mô hình request/response của ứng dụng. Chẳng hạn như một ứng dụng Web chia sẻ video, nó có thể phải tiếp nhận rất nhiều yêu cầu từ người dùng thông qua browser trong cùng 1 thời điểm. Một số yêu cầu có thể là upload video mới, mỗi yêu cầu phải được xử lý và lưu video lại để có thể truy cập về sau. Việc để người dùng phải chờ trong khi yêu cầu được hoàn thành có thể không phải là cách hay. Thay vào đó, phần ứng dụng tiếp nhận yêu cầu từ trình duyệt có thể khởi tạo một tiến trình ở hậu cảnh để xử lý công việc. Windows Azure Web Role và Worker Role có thể sử dụng đồng thời để cài đặt mô hình này. Hình 2.15 mô tả khung ứng dụng dạng này Hình 2.15: Mô hình ứng dụng có khả năng mở rộng và xử lý ở hậu cảnh [5] Mô hình này sử dụng các Web Role instance để tiếp nhận các yêu cầu từ người dùng, để hỗ trợ một số lượng lớn người dùng song song, nó có thể dùng Tables Storage để lưu thông tin. Để xử lý hậu cảnh, ứng dụng dựa trên các Worker Role instances, Worker Roles tiếp nhận các công việc dựa trên Queues. Mô hình trên cũng cho một ví dụ tốt về việc phối hợp sử dụng tất cả các thành phần cơ bản của Windows Azure như Web Role intances, Worker Role instances, Blobs, Queues và Tables trong một ứng dụng. 2.3.4. Sử dụng Cloud Storage từ các ứng dụng on-premises hoặc ứng dụng host truyền thống Đôi khi các ứng dụng on-premises hoặc ứng dụng web truyền thống cũng cần lưu một lượng dữ liệu khổng lồ. Một doanh nghiệp có thể muốn lưu trữ toàn bộ các email, một trang web tin tức có thể có nhu cầu lưu trữ khối dữ liệu lớn văn bản, hình ảnh, video, … Một trang web chia sẻ hình ảnh muốn tìm một nhà cung cấp để lưu trữ dữ liệu với dung lượng lớn và độ tin cậy cao. Windows Azure Storage có thể đáp ứng những nhu cầu trên , hình 2.16 mô tả ý tưởng này. Hình 2.16: Mô hình ứng dụng từ máy cục bộ hoặc ứng dụng web truyền thống sử dụng Cloud Storage [5] Trong mô hình trên, các ứng dụng on-premise (chạy trên máy local) hoặc các ứng dụng đang được host trên 1 máy chủ đều có thể truy nhập trực tiếp vào Windows Azure Storage, mặc dù cách truy nhập này có thể chậm hơn so với truy cập bộ nhớ địa phương, nhưng nó sẽ rẻ hơn, khả năng mở rộng cao hơn và đáng tin cậy hơn. 2.4. Triển khai ứng dụng Microsoft Windows Azure Các lập trình viên có thể xây dựng ứng dụng Windows Azure bằng bộ công cụ quen thuộc Visual Studio và gói Windows Azure Development Kit (SDK) bổ sung. Windows Azure Development Kit cung cấp project templates cho Visual Studio để hỗ trợ tạo các thành phần như Web Role, Worker Role. Ngoài ra Microsoft còn cung cấp tool Development Fabric để giả lập môi trường Windows Azure trên máy cục bộ. Development Fabric chạy trên các máy cục bộ sử dụng Visual Studio 2008 (trở lên) và hệ điều hành Windows Server 2008 hoặc Windows Vista trở về sau, nó giả lập môi trường Windows Azure với các tính năng hỗ trợ Web Role, Worker Role, các dịch vụ Storage (Blobs, Tables, Queues). Với Development Fabric, nhà phát triển có thể xây dựng ứng dụng Windows Azure với các project template trong Visual Studio, chạy và kiểm tra ứng dụng với Development Fabric, đóng gói ứng dụng với tính năng Publish trong Visual Studio. Hình 2.17: Development Fabric cung cấp môi trường giả lập Windows Azure trên máy local cho các lập trình viên [5] Các công cụ này đều có thể download tại website chính thức của Windows Azure Ứng dụng Windows Azure sau khi chạy thành công trên môi trường Development Fabric có thể triển khai lên môi trường đ