CHIẾN LƯỢC ĐỊNH GIÁ HỢP ĐỒNG
9.3. Thực nghiệm:
Để đánh giá mô hình và giải thuật trình bày trong chương này, nhóm nghiên cứu sẽ trình bày thực nghiệm mô phỏng Haizea sử dụng luồng công việc từ máy chủ BLUE2 và DS đã thực hiện trong Chương 5. Như đã nói ở chương 5, các luồng công việc này được lấy từ Parallel Workloads Archive có chú thích thời gian hết hạn (deadline) và bắt đầu (starting). Hơn nữa, mỗi yêu cầu được chú thích bởi giá trị ru.
Bên cạnh thời gian hết hạn và bắt đầu (tham số và trình bày trong phần 5.5), ta cũng theo dõi sự thay đổi nhưng tham số sau:
• Phân phối giá trị ru. Mỗi người dùng trong mỗi luồng công việc được gán
cho một giá trị từ $0.10 đến $10.00 theo bốn kiểu sau: − CHEAP USERS: Phân phối Pareto (wiki) tiến tới $0.10. − CONSTANT USERS: Luôn luôn là $1.00
− UNIFORM USERS: Các giá trị được lấy ngẫu nhiên. − RICH USERS: Phân phối Pareto tiến tới $10.00.
• Chiến lược định giá: CONSTANT, RANDOM, MAXIMUM, hoặc
ADAPTIVE (đã trình bày ở phần 8.2)
Các số ngẫu nhiên phát sinh sử dụng trình phát sinh số ngẫu nhiên của Python. Ta mô phỏng hai luồng công việc trong mỗi tổ hợp từ các tham số đó, và gán cho tham số DOWN_MULTIPLIER, UP_MULTIPLIER, và N trong giải thuật 7 lần
9.3.1. Số liệu:
Trong mỗi thực nghiệm, ta đo đạc các thông tin sau:
• Revenue: Tổng giá cả của tất cả các hợp đồng thực hiện được trong một lần thực
nghiệm. Trong mỗi lần chạy, giá trị này được chuẩn hóa tùy theo tổng doanh thu
khả thi, hoặc số doanh thu mà nhà cung cấp sẽ nhận được nếu bằng cách nào đó mà
thỏa mãn được mọi yêu cầu riêng biệt trong luồng công việc và đạt được giá tối đa người dùng sẵn sàng trả.
• Missed revenue (underpricing): Sự chênh lệch giữa mức giá tối đa của một hợp
đồng (giả sử rằng chúng ta đã tính cho người dùng mức giá họ chấp nhận được) và mức giá thực sự.
• Missed revenue (price rejected by user): Tổng giá của tất cả hợp đồng mà người
dùng từ chối, được định theo mức giá chấp nhận được của người dùng (không phải theo mức mà nhà cung cấp đề nghị).
• Missed revenue (lease could not be scheduled): Tổng giá của tất cả hợp đồng được
9.3.2. Kết quả:
Hình 19 và 20 trình bày hiệu quả của các chiến lược định giá và sự phân bố của giá trị ru trong số liệu revenue. Để tập trung vào các chiến lược giá, ta giới hạn phần thảo luận với những giá trị ít bị hạn chế về EARLY START (phải bắt đầu sớm). Trong cả 2 luồng công việc BLUE2 và DS, chiến lược ADAPTIVE thi hành tốt hơn CONSTANT và RANDOM khi xử lý UNIFORM USERS và RICH USERS, thu được từ 41.28% (TIGHT DEADLINE, UNIFORM USERS) tới 61.17% (LOOSE DEADLINE, RICH USERS) tổng số doanh thu có thể có trong các luồng công việc BLUE2 (lần lượt là 61.25% và 63.06% số doanh thu thu được khi sử dụng chiến lược MAXIMUM), và từ 36.26% (TIGHT DEADLINE, UNIFORM USERS) tới
chiến lược ADAPTIVE gần với MAXIMUM. Vì mức giá người dùng biến thiên tương đối ít cho phép chiến lược ADAPTIVE đạt được mức giá giúp tối đa doanh thu cho mọi yêu cầu, mặc dù có một vài hợp đồng bị người dùng từ chối tại thời điểm bắt đầu luồng công việc trước khi giải thuật hội tụ về mức giá cố định (tăng mức giá để xem người dùng có chấp nhận hay không).
Hình 20: Ảnh hưởng của chiến lược định giá, sự phân bố giá trị ru và lên revenue (luồng công việc DS).
Tuy nhiên, trong các trường hợp CHEAP USERS, nhiều doanh thu bị mất khi lượng giá thấp hơn thực tế. Nguyên nhân có thể là do giải thuật ADAPTIVE ước lượng mức giá thấp hơn mức đa số người dùng sẽ trả. Xem xét quá trình khi toàn bộ luồng công việc được định giá cố định biến thiên từ 0.1 tới 10.0 với mức biến thiên là 0.01 (Hình 21 và 22) cho thấy nguyên nhân
doanh thu phụ thêm từ các hợp đồng được chấp nhận không đủ để bù số lượng hợp đồng gia tăng mà người dùng từ chối. Do đó, điểm cân bằng tiến tới một mức tổng doanh thu nhỏ hơn so với các trường hợp khác. Những biểu đồ sau đây cũng thể hiện việc tập trung vào giá trị trung bình của ru đôi khi không cần thiết đối với một giải thuật tốt. Như trình bày trong trường hợp RICH USERS, đưa ra một mức giá thấp hơn giải thuật ADAPTIVE có thể cho doanh thu cao hơn.
Cuối cùng, hình 23 biểu diễn mối quan hệ giữa doanh thu và sự tận dụng tài nguyên trong mỗi chiến lược. Các kết quả này nhấn mạnh rằng tận dụng tài nguyên không bao hàm doanh thu cao. Nếu ta bỏ qua CONSTANT USERS, chiến lược định giá ADAPTIVE thể hiện mức độ biến thiên sự tận dụng tài nguyên thấp nhất. Bất chấp số người sử dụng, giá trị hay , tỉ lệ tận dụng sẽ từ 35.17% đến 47.54% (luồng công việc BLUE2) và từ 17.25% đến 33.83% (luồng công việc DS). Như vậy, trong các luồng công việc này, chiến lược định giá ADAPTIVE có thể đạt doanh thu cao hơn những chiến lược khác trong khi vẫn còn lại hơn một nửa tài nguyên khả dụng cho người dùng khác.
chạy có chiếm đóng với tạm treo/phục hồi và mọi tổ hợp có thể có của và .
9.4. Kết luận:
Chương này đã trình bày một mô hình định giá hợp đồng và chiến lược định giá ADAPTIVE giúp nhà cung cấp tài nguyên xác định được giá hợp đồng bằng cách phân tích hành vi người dùng. Đánh giá thực nghiệm đã chỉ ra được trong hầu hết các trường hợp chiến lược này đều sử dụng ít tài nguyên để kiếm doanh thu hơn các chiến lược baseline khác. Như vậy, chiến lược định giá ADAPTIVE được đánh giá rất cao.
Tuy nhiên, trong mô hình này, các nhà cung cấp tài nguyên dựa vào hành vi của khách hàng nhưng khách hàng sử dụng tài nguyên thì không phản ứng lại hành vi của nhà cung cấp. Việc dựa vào khách hàng trong những chiến lược định giá này dường như chỉ xuất hiện trong thực tế, và có thể sẽ thay đổi các kết quả trình bày ở
Bước tiếp theo sẽ là xử lý tài nguyên không bán được. Như đã được nêu trong chương này, hỗ trợ QoS và giá cả có thể làm giới hạn số hợp đồng nhà cung cấp chấp nhận, và kết quả là tài nguyên không được sử dụng. Tuy nhiên, các thực nghiệm chỉ dựa vào các luồng công việc tồn tại. Mặc dù mô hình có bao gồm mức giá người sử dụng sẽ trả tiền cho hợp đồng của họ nhưng lại không mô hình được làm thế nào người dùng khác có thể sử dụng tài nguyên còn lại. Một phát triển thích hợp gần đây của Amazon EC2 gọi là spot pricing. Đây là cách cho phép những tài nguyên không sử dụng trong EC2 được bán với giá thấp hơn. Vì vậy sẽ có bảo đảm QoS ít hơn. Tuy nhiên, không giống như Amazon, ta mong muốn phát triển một mô hình có thể kết nối cả những hợp đồng QoS cao (loại AR hoặc có thời hạn) và những hợp đồng QoS thấp hơn (nhưng không quá thấp) lại với nhau. Hợp đồng QoS thấp hơn là những hợp đồng thường sử dụng như là ‘economic backfilling’ cho tài nguyên không sử dụng và dùng làm đòn bẩy để máy ảo tạm treo, phục hồi hay di dời để phục vụ chiếm lấp (không giống như trường hợp EC2 spot, sẽ bị tiêu đi khi mức giá spot vượt quá mức giá khách hàng).
Ta cũng sẽ khảo sát những chiến lược giá khác nữa, gồm một vài chiến lược có cân nhắc đến mức độ QoS yêu cầu khi đặt giá. Ví dụ như đặt mức giá cao hơn đối với những hợp đồng có thời hạn ngắn hơn. Một chiến lược phù hợp sẽ bắt buộc thêm tiền nếu yêu cầu chiếm lấp hợp đồng khác, ngay khả khi hợp đồng bị chiếm lấp vẫn được đáp ứng đúng thời hạn. Việc chiếm lấp có bao gồm thời gian tạp treo và phục hồi hợp đồng và khoảng thời gian tài nguyên vật lý rảnh essentially (vì đang sử lý tác vụ chi phí chứ không phải điện toán thực). Vì thời hạn ngắn hơn có khả năng làm tăng số hợp đồng bị chiếm lấp nên việc gán thêm tiền là một cách gián tiếp để phục vụ cho loại có QoS cao hơn.
Cuối cùng, hiện nay ta giả định rằng một khi hợp đồng được chấp nhận thì không thể phá vỡ các điều kiện của hợp đồng được. Nói cách khác, trình lập lịch sẽ
phạm hợp đồng. Thay vào đó sẽ nhà cung cấp sẽ trả một khoảng penalty cho người dùng. Và nhà cung cấp sẽ có thể đề nghị mức giá với người dùng với mỗi khoảng penalty khác nhau: một khoảng penalty cao sẽ dành cho những mức giá cao nhưng sẽ ít bị vi phạm điều khoảng hợp đồng hơn.