I khai quat websphere extreme scale tron

I Khái quát WebSphere eXtreme Scale WebSphere eXtreme Scale mạng lưu trữ liệu nhớ Ram (in-memory data grid) có khả mở rộng mềm dẻo Nó tự động lưu trữ cache, phân vùng, tạo sao, quản lý liệu business-logic ứng dụng nhiều server WebSphere eXtreme Scale cịn thực thi xử lý lượng khổng lồ giao tác (transaction) với hiệu cao, khả mở rộng tuyến tính cung cấp dịch vụ có chất lượng tính thống transaction, độ sẵn sàng cao dự đoán thời gian phản hồi Khả mở rộng mềm dẻo có nhờ việc phân tán đối tượng lưu trữ (distribute object caching) Mạng phân tán tự kiểm tra quản lý nó, cho phép scaleout, scale-in khả tự hồi phục sau cố Scale-out cho phép tăng thêm nhớ mạng liệu hoạt động mà không cần phải khởi động lại, scale-in có khả loại bỏ nhớ tức thời WebSphere eXtreme Scale sử theo nhiều hướng lưu trữ cache hay sở liệu sử dụng nhớ Ram Nhưng theo phạm vi luận này, quan tâm tới việc WebSphere eXtreme Scale sử dụng để lưu trữ cache Giả sử bạn có sở liệu lưu trữ data, chuyện xảy máy lưu trữ liệu bị hỏng Nếu sở liệu thông thường, việc phục hồi điều khơng thể Thậm chí tồn liệu lưu máy thảm họa Để giải vấn đề này, eXtreme Scale chia liệu bạn thành phân vùng nhỏ, phân vùng bao gồm shard (mảnh) nhiều shard dùng để backup liệu WebSphere eXtreme Scale thực chức cách hoàn toàn tự động WebSphere eXtreme Scale cung cấp lựa chọn việc giao tiếp với database lưu trữ liệu ứng dụng, cache đồng cache không đồng Cache không đồng hay gọi write-behind cache cho phép WebSphere eXtreme Scale hoạt động front-end cache cho database Việc lưu liệu vào Data-Grid vào database cách không đồng cải thiện thời gian phản hồi cho ứng dụng, tăng throughput cho liệu vào Data-Grid Cache đồng hay gọi write-through cache cho phép liệu update vào Data-Grid đồng thời liệu update vào Database Phương pháp giúp liệu quán với Database backend lại giảm hiệu suất ghi liệu Hình ảnh cho thấy mơi trường phân tán, quán cache Ứng dụng client gửi nhận liệu từ grid, grid sau tự động đồng khơng đồng với data backend Cache thống tất client nhìn thấy cache grid cách giống thống nhất, phần nhỏ data lưu trữ xác server grid, cách ngăn chặn việc có nhiều data mang phiên khác Về độ sẵn sàng (Availability), phân vùng bao gồm mảnh shard mảnh shard Thay đổi tới shard ánh xạ sang shard sao, shard WebSphere eXtreme Scale phân tán server chứa mạng liệu, để đảm bảo, việc phân tán hoạt động cho shard shard khơng năm máy server vật lý Hình ta thấy diện Catalog Service Việc phân tán shard nhờ hoạt động service Ví dụ server chứa shard bị lỗi, Catalog service định vị server chứa shard mới, hay shard ngừng hoạt động, shard định trở thành shard shard khác sinh II Khái niệm Caching Cấu trúc nhớ cache 1.1 Maps - Map chứa cặp key-value, cho phép ứng dụng lưu trữ, truy vấn value key Những value dùng để lưu trữ thông tin, trạng thái ứng dụng - Map set tập hợp map có chung thuật tốn phân vùng Dữ liệu map tạo tùy thuộc vào quy ước đặt map set 1.2 Container, phân vùng shard Container dịch vụ lưu trữ liệu ứng dụng cho grid Dữ liệu chia thành phần nhỏ gọi phân vùng chứa nhiều containers Một máy chủ vật lý có nhiều máy chủ ảo Java virtual Machine (JVM), JVM lại chứa nhiều container container lại chứa nhiều shard Tất container hợp thành ObjectGrid hay Grid mạng liệu Phân vùng chứa tập liệu hoàn chỉnh grid WebSphere eXtreme Scale đặt phân vùng vào container tự động trải rộng có nhiều container available Shard trường hợp đặc biệt phân vùng mang hai vai trò: Bản shard thể vật lý phân vùng Mỗi phân vùng có nhiều shard chứa tất liệu nằm phân vùng đó, shard shard cho phép transaction ghi vào cache Tất shard lại shard phép transaction đọc liệu Những shard ánh xạ đồng khơng đồng từ shard Ngồi shard khơng chứa container với máy chủ vật lý Cache phân tán WebSphere eXtreme Scale dùng share cache, cung cấp truy cập transaction tới liệu từ nhiều thành phần hợp thành khác 2.1 Far cache Client truy cập liệu tới grid từ xa nên gọi nhớ cache “Far cache” Bộ nhớ Cache hồn chỉnh mạch lạc tất client nhìn thấy liệu cache giống Mỗi phần nhỏ liệu lưu trữ xác server nhớ cache, giúp ngăn chặn việc có nhiều liệu với phiên khác Bộ nhớ cache thống cịn lưu trữ thêm nhiều liệu nhiều server thêm vào Data grid mở rộng tuyến tính kích thước grid tăng lên Ngồi việc xác minh loại bỏ cache (invalidate cache) trở nên khơng cần thiết tính thống cache giúp khơng lưu trữ liệu cũ Bộ nhớ cache thống lưu trữ phiên phần nhỏ data 2.2 Near cache Client lựa chọn dùng local cache mơ hình cache phân tán Cache tùy chọn gọi “near cache”, ObjectGrid hoàn toàn độc lập client, phục vụ cache “far cache” server từ xa Near cache hoạt động nhanh cung cấp truy cập phần liệu được lưu trữ client nhớ Ram Nhìn hinh thấy near cache khơng bị phân vùng WebSphere eXtreme Scale có tầng cache sau Tầng transaction lưu trữ tất thay đổi transaction, lưu trữ phiên làm việc liệu transaction cam kết (commited) Khi client transaction yêu cầu liệu từ OjectGrid, tầng transaction kiểm tra Near cache tầng client lưu trữ phần liệu từ tầng server Khi tầng transaction khơng có liệu mà client yêu cầu, liệu lấy từ near cache (nếu có) đặt vào tầng transaction Mạng liệu (data grid) tầng server lưu trữ phần lớn data chia sẻ cho tất client Dữ liệu tầng phân vùng cho phép lưu trữ lượng liệu lớn vào nhớ cache Khi near cache tầng client khơng có liệu mà client yêu cầu, liệu lấy từ data grid tầng server đưa vào near cache tầng client Trường hợp mà data grid liệu yêu cầu, Loader plug-in tầng server gọi lấy liệu từ backend database đưa vào data grid Ưu điểm near cache thời gian phản hồi nhanh liệu lưu local Nhược điểm tăng khoảng thời gian tồn liệu cũ, phải dùng evictor để xác minh loại bỏ cache, tránh việc liệu bị tràn Sử dụng yếu tố thời gian phản hồi quan trọng liệu cũ chấp nhận Tích hợp sở liệu WebSphere eXtreme Scale dùng để thay cho sở liệu truyền thống, giảm công việc đọc liệu từ Database 3.1 Sparse cache complete cache WebSphere eXtreme Scale dùng theo sparse cache complete cache Spase cache phần toàn liệu complete cache chứa toàn liệu 3.2 Side cache WebSphere eXtreme Scale sử dụng side-cache cho lớp truy cấp liệu ứng dụng (Data access layer) Trong vai trò này, eXtreme Scale tạm thời lưu liệu mà thường xuyên truy cập sở liệu back-end Ứng dụng kiểm tra xem eXtreme Scale có chứa liệu mà mong muốn khơng Nếu có, liệu trả Nếu không, liệu lấy từ back-end đồng thời đặt liệu vào eXtreme Scale lấy từ cho request từ ứng dụng Hình biểu diễn side cache sử lớp truy cập liệu OpenJPA hay Hibernate 3.3 In-line cache Khi dùng in-line cache, eXtreme Scale giao tiếp với back-end cách sử dụng Loader plug-in Trong vai trò này, ứng dụng trực tiếp truy cập liệu từ eXtreme Scale vài phương pháp để đảm bảo liệu cache liệu back-end đồng In-line cache đơn giản hóa việc truy cập liệu cho phép ứng dụng truy cập tới eXtreme Scale cách trực tiếp WebSphere eXtreme Scale hỗ trợ kịch in-line cache sau  Read-through  Write-through  Write-behind Read-through Read-through cache sparse cache, load liệu key mà client request Nếu liệu khơng tìm thấy eXtreme Scale cache Loader plug-in gọi Lấy liệu từ back-end đồng thời đặt liệu vào cache Những Request cho key liệu lấy từ cache liệu bị loại bỏ Write-through Với write-through cache, thay đổi ghi liệu tới cache thay đổi đồng tới Database cách sử dụng Loader Cách mang lại tính quán với back-end lại giảm hiệu ghi liệu liệu phải cập nhật đồng Vì cache database cập nhật nên request cho liệu lấy từ nhớ cache, tăng hiệu khơng phải truy vấn từ database Write-behind Hiệu giảm đồng với sở liệu write-through cải thiện cách không đồng Phương pháp gọi write-behind write-back cache Dữ liệu tạm thời đưa vào nhớ đệm sau ghi lại vào database background thread Lợi ích mà write-behind mang lại  Cô lập lỗi xảy backend: Khi backend xảy lỗi, write-behind cache tạo lớp cô lập với backend, update đến database queue queue map, ứng dụng tiếp tục thực transaction eXtreme Scale Khi backend hồi phục, liệu queue map đẩy vào backend  Giảm load backend: write-behind loader nhóm update dựa vào key Do nhóm update có key queue map, giảm thiểu số lần update database  Tăng hiệu suất cho transaction: Thời gian cho transaction giảm transaction khơng phải đợi liệu đồng với backend 3.4 Kỹ thuật đồng hóa sở liệu Khi WebSphere eXtreme Scale sử dụng nhớ cache, ứng dụng viết phải loại bỏ liệu cũ database update độc lập với eXtreme Scale transaction eXtreme Scale cung cấp phương pháp sau để giữ data cập nhật Periodic Refresh: Bộ nhớ cache tự động loại bỏ liệu cũ (invalidated) update theo chu kỳ cách sử dụng Java Persistence API (JPA) Truy vấn tới database thực theo chu kỳ Bất kỳ thay đổi định danh tự động cập nhật tới nhớ cache Eviction: Sparse cache sử dụng eviction để tự động loại bỏ liệu khỏi nhớ cache mà khơng động tới database Có ba kiểu mẫu eviction có sẵn WebSphere eXtreme Scale  None: liệu lưu vào cache không bị loại bỏ khỏi map  Creation time: liệu lưu vào cache bị loại bỏ phụ thuộc vào thời gian tạo  Last access time: liệu lưu vào cache bị loại bỏ phụ thuộc vào thời gian lần cuối truy cập Khi chọn creation time, liệu bị loại bỏ thời gian sống liệu với thời gian thuộc tính TimeToLive Tức set giá trị TimeToLive cho liệu 10 giây sau 10 giây kể từ tạo ra, liệu tự động bị xóa Cịn chọn last access time, nên set TimeToLive số khơng q lớn Vì TimeToLive tự động reset liệu truy cập Ví dụ set TTL liệu 15 giây, liệu cache tồn 14 giây lại vừa truy cập, TTL lại reset 15 giây III Khả mở rộng WebSphere eXtreme Scale chia liệu thành phân vùng riêng biệt, phân vùng di chuyển máy ảo máy tính vật lý khác thời gian chạy Ví dụ ban đầu bạn có server triển khai sau bạn muốn tăng số lên 10 server nhu cầu lưu trữ cache tăng Thay mở rộng vertical, tức thêm máy chủ vật lý thêm phần cứng processor, bạn mở rộng horizontal cách phân vùng Đây khác biệt lớn WebSphere eXtreme Scale so với sở giữ liệu nhớ thông thường Mạng liệu (grid data) có nhiều phân vùng, hàng nghìn phân vùng cần thiết Nó mở rộng tới số số phân vùng nhân với số shard có phân vùng Ví dụ bạn triển khai liệu cache ứng dụng có 16 phân vùng, phân vùng có shard shard sao, theo cơng thức trên, bạn có tiềm mở rộng đến 32 máy ảo (JVM) Con số phân vùng phải lựa chọn tính tốn cẩn thận dựa số máy ảo mà bạn muốn dùng Cân nhắc ví dụ khác như: bạn có máy chủ máy có máy ảo Bạn mong muốn ba năm dùng tới 30 máy chủ Với 30 máy chủ, bạn có 60 máy ảo, máy ảo bạn lại muốn có shard Vậy tổng cộng bạn có 240 shard 60 container Sau bạn định có shard shard sao, bạn cần 120 phân vùng Vậy bạn cần 240 chia 12 máy ảo ban đầu 20 shard cho máy ảo Do bạn với máy chủ ban đầu 20 shard máy ảo, bạn có khả mở rộng 30 máy chủ sau Có hai cách đặt có sẵn cho phân vùng  Fixed partition placement  Per-container placement Fixed partition placement Số phân vùng thiết lập trước Với cách này, số shard đúng số phân vùng thiết lập trước Con số shard nhỏ tính cơng thức ((1 shard + số shard đồng nhỏ nhất)*số partition) Con số lớn mà shard thiết lập ((1 shard + số shard đồng lớn + số shard khơng đồng lớn nhất)*số partition) Ví dụ số phân vùng giá trị shard đồng nhỏ 1, tổng số shard 12 Nếu có container WebSphere eXtreme Scale đặt shard cho container Per-container placement Thay xác đinh số phân vùng cho grid, bạn thiết lập số phân vùng cho container Và tổng số phân vùng tự động tăng lên giảm xuống tương ứng với việc thêm vào loại bỏ container grid Ta có ví dụ sau: Bắt đầu với container C0 với shard (P0 – P4) o C0 có: P0, P1, P2, P3, P4 Thêm vào container C1 với thêm shard (P5 - P9) Shard phụ tự động cân container o C0 có: P0, P1, P2, P3, P4, R5, R6, R7, R8, R9 o C1 có: P5, P6, P7, P8, P9, R0, R1, R2, R3, R4 Tiếp tục thêm container C2 với shar chinh nưa (P10 – P14) Shard phụ tiếp tục cân o C0 hosts: P0, P1, P2, P3, P4, R7, R8, R9, R10, R11, R1 o C1 hosts: P5, P6, P7, P8, P9, R2, R3, R4, R13, R14 o C2 hosts: P10, P11, P12, P13, P14, R5, R6, R0, R1 Mơ hình tiếp tục mở rộng nhiều container thêm vào IV Tính sẵn có Tạo Với WebSphere eXtreme Scale, shard tạo từ máy ảo (JVM) đến máy ảo khác Shard đại diện cho phân vùng đặt container Mỗi phân vùng bao gồm shard một vài shard Shard đồng khơng đồng Shard có kiểu  Bản  Đồng  Khơng đồng Shard bị tác động tất trình insert, update, remove Shard điều khiển việc tạo sao, commit rollback cho transaction Shard đồng trạng thái với shard Khi shard tạo cho shard đồng bộ, transaction không commit việc tạo thành công shard đồng Shard khơng đồng có khơng trạng thái với shard Transaction thực mà không cần chờ trường hợp shard đồng 2 Phục hồi liệu sau lỗi 2.1 Vòng đời shard Khi shard định làm shard chính, nhận danh sách từ catalog service Shard tiếp tục tạo group đăng ký với group Khi shard lần hoạt động, chưa làm việc ngang hàng với shard Cả hai shard đồng shard không đồng phải bắt đầu với chuỗi khởi động giống Shard tạo điểm nhớ checkpoint, lấy liệu shard từ điểm nhớ Dữ liệu điểm nhớ đưa tới shard tiếp nhận transaction mà khơng bị gián đoạn Đồng thời shard lưu lại thay đổi từ điểm nhớ checkpoint sau đẩy vào Sau trình tạo kết thúc, shard bắt đầu chạy đồng hoăc không đồng đẩy lên hoạt động ngang hàng với shard 2.2 Phục hồi liệu Nếu shard xảy lỗi, shard định thay Nếu shard phụ xảy vấn đề cố gắng để phục hồi Catalog service lựa chọn shard đồng định làm shard Shard đăng ký với tất shard tồn từ trước nhận transaction bình thường Ví dụ cho partition với thông số triển khai ban đầu minSyncReplica 1, maxSyncReplica 2, maxAsyncReplica Shard xảy lỗi Shard đồng Container định trở thành shard Shard đăng ký với shard tồn từ trước hoạt động bình thường Nếu shard phát lỗi, trigger kiện đăng ký để thay liệu cũ Shard xóa hết liệu trước nhận copy từ shard