Tải bản đầy đủ - 0 (trang)
CHƯƠNG 3. GIẢI PHÁP PHÂN CỤM CHO KURENTO MEDIA SERVER

CHƯƠNG 3. GIẢI PHÁP PHÂN CỤM CHO KURENTO MEDIA SERVER

Tải bản đầy đủ - 0trang

có thể là tập hợp bao gồm STUN, TURN server được đặt ở các đối tượng là peer và

KMS. Phần này đã được giới thiệu ở phần 2.1.4

Các đối tượng này sẽ tham gia vào trong quá trình thực hiện cuộc gọi video.Về cơ bản ta có

thể chia q trình này thành 3 q trình con là đăng kí,thực hiện cuộc gọi,kết thúc cuộc

goi.Chi tiết về quá trình thực hiện sẽ được mơ tả bên dưới.



3.1.1 Đăng kí người dùng

Bước này thực hiện khá đơn giản với việc có 3 tác nhân là người dùng A, người dùng

B và signaling server.Server này sẽ là trung gian xử lý các yêu cầu đăng kí của hai bên (ví dụ

có thể lưu vào database).Nó cũng đưa ra các quyết định liệu có thể cho người dùng đăng kí

hay khơng.Có hai trạng thái mà nó gửi về cho người dùng ở bước này là đăng kí thành cơng

và đăng kí thất bại. Hình dưới mơ tả pha đăng kí người dùng.



Hình 3.2 Mơ tả q trình đăng kí



3.1.2. Thực hiện cuộc gọi

Bước chủ yếu được giới thiệu ở đây là thực hiện cuộc gọi.Ở bước này các peer sẽ phải

thực hiện một số trao đổi nhất định để có thể đạt được kết nối với KMS. Các trao đổi này

được trung gian qua Signaling Server và lấy được candidate thông qua các ICE đứng bên cạnh

các đối tượng.Dưới đây là mô tả chi tiết các quy trình để thực hiện một cuộc gọi video.



32



Quy trình lấy được SDP



Hình 3.3 Mơ tả q trình bắt đầu lấy SDP

Khi thực hiện việc đăng kí thành công,để bắt đầu thiết lập cuộc gọi, mỗi bên cần biết một

thông số nhất định.Đầu tiên, bắt đầu khởi tạo một đối tượng là WebRtcPeer ( đã nhắc qua ở

chương 2).Sau đó ta bắt đầu thiết lập một callback để lắng nghe SDP offer được gửi về. Khi

nhận được SDP thành công, Peer A bắt đầu gửi yêu cầu cấp quyền truy cập một số tài nguyên

thiết bị tới người dùng.Nếu người dùng đồng ý, chúng ta bắt đầu thực hiện q trình tiếp theo

là gửi các thơng tin ban đầu từ Peer A ( như là SDP, đến từ đâu, muốn kết nối tới đâu…) đến

signaling.Signaling có nhiệm vụ lưu lại các thông tin này và bắt đầu thông báo tới trình duyệt

B là có ai đó muốn kết nối.Khi Peer B nhận được thông báo bên A muốn kết nối, nó sẽ thiết

lập tương tự như Peer A khi lấy SDP offer và truy cập thiết bị. Khi đó Signaling sẽ có thơng

tin của hai Peer và bắt đầu vào quá trình thiết lập cuộc gọi với KMS.

Trao đổi ứng viên (candidate)



Hình 3.4 Quá trình thu thập candidate từ trình duyệt và trao đổi với KMS



33



Quá trình này song song với q trình đạt được SDP, mục đích của quá trình này nhằm

mở ra các cách khác nhau mà cách peer khác có thể kết nối với A.Đầu tiên ta cần làm là đăng

kí lắng nghe candidate tới ICE peer A bằng cách ta sẽ thiết lập một callback là

OnIceCandidate ( đây là một option khi tạo đối tượng WebRtcPeer).Khi đó,ICE cho trình

duyệt A sẽ thực hiện chức năng của nó là tìm các cách để có thể kết nối với A. Khi tìm được,

nó sẽ gửi lại cho trình duyệt A thơng qua hàm callback OnIceCandidate.Bước tiếp theo trình

duyệt A gửi lại cho signaling server, server này đơn giản là ủy quyền lại cho Kurento Media

Sever (KMS) bằng cách gọi addCandidate để yêu cầu thêm vào các cách để kết nối với A

(candidate).Vì vậy KMS sẽ biết cách để kết nối với peer A.Việc này tương tự với Peer B.



Hình 3.5 Quá trình KMS trao đổi candidate với các peer

Quá trình này được thực hiện khi mà WebRtcEndpoint đã được tạo ra bên trong KMS.

Khi đó ta cần biết cách để biết làm sao để kết nối với WebRtcEndpoint tương ứng. Bằng cách

thêm vào một máy chủ ICE bên cạnh KMS ( có thể là STUN hoặc TURN). Nó sẽ nói cho

KMS biết làm cách nào để kết nối với WebRtcEndpoint trong đó.Từ đó KMS sẽ gửi các cách

kết nối với WebRtcEndpoint này (candidate) trở lại chỗ mà nó đã đăng kí mỗi khi mà máy chủ

ICE gửi trả về một candidate tương ứng.Các candidate này được gửi trở lại các peer qua

Signaling làm trung gian.Các peer sẽ thực hiện công việc cuối cùng là thêm cái candidate đó

vào (bằng cách thực hiện addCandidate ở đối tượng WebRtcPeer) và q trình này có thể sẽ

phải lặp lại nhiều lần. Nếu q trình trao đổi thành cơng, Peer sẽ biết cách để kết nối với

WebRtcEndpoint trong KMS vừa tạo.Kết quả từ hai quá trình kể trên là các Peer và KMS đã

hiểu cách kết nối với nhau.



34



Bắt đầu thiết lập cuộc gọi

Ngay sau khi B chấp nhận kết nối, chúng ta bắt đầu thiết lập các bước cần thiết để có

thể đạt được cuộc gọi giữa hai.Trọng phần này các bước sẽ được thực hiện ở Signaling, dưới

đây là mô tả các bước Signaling cần thực hiện để thiết lập cuộc gọi.



Hình 3.6: Quá trình kết nối với KMS và tạo các thành phần cần thiết cho việc thực hiện cuộc gọi

Ở bước này đầu tiên ta cần phải tạo một kurentoClient bằng cách gọi hàm kurento

( được kurento cung cấp ) nhằm kết nối tới KMS.Sau khi đã kết nối được với KMS,chúng ta

cần gửi yêu cầu đến tạo một pipeline, chúng ta sử dụng đối tượng kurentoClient đã tạo trước

đó gọi hàm create (được thiết kế để tương tác với KMS như đề cập ở chương trước) với tham

số là MediaPipeline.Tiếp đó, ngay sau khi có được pipeline, chúng ta cần hai

WebRTCEndpoint cho hai trình duyệt tương ứng A và B. Mục đích của việc này là để các

luồng media hoạt động trên KMS có thể trao đổi với nhau.



35



Hình 3.7 Quá trình kết nối hai WebRtcEndpoint

Mặc dù đã tạo hai WebRTCEndPoint nhưng chúng ta cần phải làm một điều là kết nói

chúng lại với nhau,việc kết nối này được thực hiện trên cả hai WebRTCEndPoint. Thực hiện

điều này bằng cách sử dụng đối tượng hai đối tượng WebRTCEndPoint ở trên và thực hiện gọi

invoke với tham số là ‘connect’. Việc này được thực hiện lần lượt với cả hai

WebRTCEndPoint.



Hình 3.8 Quá trình trao đổi SDP và bắt đầ thiết lập kết nối giữa các peer và KMS



36



Bước cuối cùng trong việc thực hiện thiết lập cuọc gọi là việc trao đổi SDP với

KMS.Bên phía signaling đã có hai SDP offer được gửi cho nó từ lần trước.Cái signaling làm

là gọi sử dụng đối tượng WebRTCEndPoint mà KMS đã trả về từ trước, gọi hàm processOffer

với tham số là SDP offer tương ứng với mỗi peer và một callback.Khi thực hiện điều này, bên

phía KMS sẽ đáp lại SDP answer và gửi trả về tương ứng với mỗi peer.Sau khi nhận được

SDP answer, mỗi peer sẽ gọi processAnswer để xử lý SDP answer được trả về. Từ đây mỗi

peer có thể tương tác với nhau, gửi/nhận dữ liệu media qua KMS.



3.1.3. Kết thúc cuộc gọi

Pha cuối cùng trong quy trình là ngừng cuộc gọi. Khi có yêu cầu ngừng từ một peer,

peer này sẽ kết thúc phiên tương tác bằng cách ngắt kết nối camera và gửi yêu cầu tới

signaling, signaling sẽ tiếp tục gửi lại yêu cầu này tới peer đang tương tác và thực hiện tương

tự. Tiếp theo signaling sẽ gửi tới KMS yêu cầu ngắt kết nối với hai peer và giải phóng tài

ngun, kết thúc phiên làm việc. Hình dưới mơ tả phiên làm việc kết thúc tương tác.



Hình 3.9 Quá trình kêt thúc cuộc gọi



3.2. Một số tình huống phân tải trên kurento

Như đã đề cập trong mục 2.4, có rất nhiều kiến trúc phân tải phổ biến được sử

dụng.Mục đích của nghiên cứu xây dựng giải pháp phân cụm.Vì thế ở đây ta chọn giải pháp

phù hợp nhất là sử dụng kiến trúc Load Balancer (Reverse Proxy).Chi tiết về cách tiếp cận sẽ

được làm rõ ở các phần dưới.



3.2.1 Tình huống phân tải phổ biến

Một trong nhưng kiến trúc phân tải phổ biến thường gặp là có một Reverse Proxy, nó được

đặt trước một hoặc nhiều web server. Khi client muốn gửi các yêu cầu tới các web server, các

yêu cầu này bị chặn lại bởi reverse proxy. Proxy server này gửi yêu cầu và nhận đáp lại từ các



37



web server. Thông thường để vận chuyển các yêu cầu ta sử dụng các yêu cầu HTTP để thực

hiện. Nhưng như đã đề cập đến trước đó,mục đích của ta là sử dụng các WebRTC API bên

phía client và điều khiển các KMS đứng sau bằng các JSON-RPC 2. Reverse proxy tương

thích với điều đó, đòi hỏi ta phải có phải pháp mở rộng hơn.



Hình 3.10 Tình huống phân tải phổ biến của ứng dụng web



3.2.2. Tình huống phân tải cho kurento media server

Với các ứng dụng web thông thường ta chỉ cần thực hiện một yêu cầu cho một mục

đích cụ thể.Các yêu cầu này được gửi thông qua một proxy và sau đó proxy này sẽ quyết định

xem nó chuyển tiếp yêu cầu này tới server nào khác. Nhưng đối với ứng dụng media có chút

khác biệt. Khi ta muốn thực hiện một chức năng media nào đó, chúng ta phải thực hiện hàng

loạt các yêu cầu trao đổi liên tiếp tới media server. Nếu cố gắng ta cũng có thể dùng các

HTTP để thực hiện việc trao đổi này. Nhưng trong trường hợp ta sử dụng ở đây là kurento

media server, như đã đề cập ở chương 2.3 là để tương tác với KMS ta cần phải sử dụng giao

thức là JSON-RPC 2. Vì thế nếu muốn thực hiện ứng dụng media theo kiến trúc web thông

thường, ta cần phải thay đổi KMS chúng ta có thể điều khiển bằng HTTP thay vì JSON-RPC

2 để proxy có thể tương thích với KMS. Việc thay đổi này thực sự khó thực hiện và đi ngược

lại mục đích nghiên cứu là xây dựng giải pháp mở rộng. Thêm vào đó, các ứng dụng

multimedia khác với ứng dụng web thông thường. Với các ứng dụng web thông thường, ta

thường chỉ cần gửi một yêu cầu tới một server và sẽ được gửi lại tương ứng có thể nói đây là

quan hệ 1-1. Nhưng với ứng dụng multimedia và cụ thể đây là sử dụng KMS ta cũng gửi một

yêu cầu với một chức năng nhất định tới KMS, nhưng ta phải trao đổi n yêu cầu con khác để

hoàn tất quá trình thực hiện q trình này có gọi là quan hệ 1-n. Chính vì thế việc phân tải sẽ

gây khó khăn hơn khi phải đảm bảo là các yêu con này không bị phân tán tới các media server

trên cùng hệ thống,vì thể sử dụng websocket có thể phù hợp hơn khi sử dụng HTTP. Có



38



nhiều giải pháp để thực hiện tốt việc này, nhưng giải pháp được trình bầy và được thực hiện

trong đồ án này là xây dựng một API GATEWAY đứng sau các KMS.



Hình 3.11 Tình huống phân tải với ứng dụng media thực hiện bới kurento

Quan sát hình ta thấy khơng có sự thay đổi gì so với Reverse Proxy. Nhưng thay vì

chúng ta thực hiện trao đổi với các server bằng các HTTP như hệ thống web phổ biến. Ta thay

vào đó là giao thức JSON-RPC 2 tương tác dựa trên websocket. Nhiệm vụ của API

GATEWAY đứng giữa là nhận các yêu cầu JSON-RPC 2 từ client (ở trong ứng dụng của ta là

signaling server), chuyển tiếp yêu cầu này sang KMS theo thuật toán phân tải nào đó và nhận

lại các yêu cầu hồi đáp (response) từ KMS và gửi lại cho client . Có nhiều cách trong việc

phân tải trên KMS, chi tiết một số cách được trình bầy ở phần dưới.



3.2.3. Một số thuật tốn phân tải phổ biến

Có nhiều thuật tốn được hỗ trợ trong việc thực hiện load balancer. Ở phần này sẽ nêu

ra 5 thuật toán cân bằng tải phổ biến.

Round Robin

Round Robin [26] là một thuật toán được sử dụng phổ biến, nó dễ dàng để thực hiện

và để hiểu. Cho là có 2 KMS đứng đằng sau một API GATEWAY. Khi mà yêu cầu thực hiện

ứng dụng media đầu tiên đến, API GATEWAY sẽ yêu cầu kết nối với này tới KMS 1 và thực

hiện các trao đổi cần thiết. Khi yêu cầu thứ 2 đến, yêu cầu tiếp theo sẽ được chuyển tới KMS

2. Vì chỉ có hai KMS nên khi có yêu cầu thứ 3 sẽ được API GATEWAY sẽ kết nối trở lại với

KMS 1, tương tự yêu cầu thứ 4 sẽ kết nối tới KMS 2.



39



Hình 3.12 Minh họa thuật tốn phân tải Round Robin

Như đã thấy, cách thức hoạt động của thuật tốn này đơn giản. Tuy nhiên, nó sẽ hoạt

động khơng tốt trong một vài tình huống. Cho ví dụ, nếu KMS 1 có nhiều CPU, RAM và các

tài nguyên hệ thống khác hơn KMS 2 đồng nghĩa với việc KMS 1 sẽ xử lý được nhiều hơn so

với KMS 2 nhưng với thuật tốn này nó chỉ xử lý ngang bằng với KMS 2.Điều này gây lẵng

phí tài nguyên cho KMS 1. API GATEWAY sử dụng thuật toán round robin sẽ khơng thể tối

ưu hóa việc phân tải với 2 media server. Mặc dù khả năng của hai server là khác nhau nhưng

API GATEWAY vẫn phân tải bằng nhau. Kết quả là KMS 2 có thể bị quá tải nhanh hơn trong

khi KMS 1 vẫn còn tài nguyên hệ thống khơng được tận dụng. Round robin là thuật tốn tốt

cho các server có thơng số kĩ thuật giống nhau. Ở các tình huống khác, ta có thể có thuật tốn

khác thích hợp hơn, ví dụ như thuật tốn bên dưới.

Round Robin trọng số (Weighted Round Robin)

Như đã đề cập ở tình huống trên, ta có KMS 1 mạnh mẽ hơn KMS 2. Ta cần phải có

thuật tốn tốt hơn để tận dụng tối đa khả năng của các server. Một thuật toán được đề cập ở

đây là Round Robin trọng số.

Round robin trọng số [26] tương tự như như Round Robin bình thường, nó vẫn xử lý

các u cầu theo chu kì. Một điểm khác biệt là các KMS nào có thơng số cao hơn sẽ được

phân bố số lượng yêu cầu nhiều hơn. Về cơ bản thông tin về KMS sẽ được thiết lập ở API

GATEWAY trước đó, vì vậy nó sẽ biết media server nào có nhiều khẳ năng hơn. Việc ta cần

làm là gắn một trọng số cho các KMS, và hiển nhiên các KMS nào có cấu hình tốt hơn sẽ có

trọng số cao hơn.Ta thường gắn trọng số sao cho phù hợp với khả năng thực tế. Cho ví dụ,

nếu ta xác định được KMS 1 mạnh hơn gấp 3 lần KMS 2, sau đó ta gắn KMS 1 với trọng số

là 3 và KMS 2 với trọng số là 1.



40



Hình 3.13 Minh họa thuật tốn phân tải Weighted Round Robin

Khi bên phía client bắt đầu đến, 3 cái đầu tiên sẽ được kết nối với KMS 1 và cái thứ 4

sẽ tới KMS 2, cứ như thế diễn ra theo chu kì.Khả năng của server không chỉ là lý do duy nhât

để chọn thuật tốn Round Robin trọng số. Đơi khi ta muốn một server có số lượng kết nối

thấp hơn các server còn lại có thể một vài lý do là server này thực hiện các nhiệm vụ quan

trọng. Thuật toán này khá tốt để giải quyết tình huống đó.

Ít kết nối nhất (Least Connections)

Có một vấn đề là khi, thậm chí khi mà 2 server có cùng thơng số, một server cũng có

thể q tải nhanh hơn server còn lại. Một lý do là bởi vì các client kết nối tới server 2 phải xử

lý lâu hơn khi kết nối với server 1. Điều này có thể gây ra tổng số lượng kết nối tới server 2

nhiều hơn server 1. Hình dưới minh họa khi A và B đã ngăt kết nối trong khi C vẫn còn kết

nối.



Hình 3.14 Hình minh họa thuật toán Round Robin khi một số kết nối bị ngắt



41



Trong trường hợp này thuật toán Least Connections [26] sẽ phù hợp nhất. Thuật tốn

này có trách nghiệm xem số lượng kết nối với mỗi KMS. Khi một client cố gắng kết nối, API

GATEWAY sẽ cố gắng xác nhận server nào có ít kết nối nhất và sau đó tạo một kết nối mới

tới server đó.



Hình 3. 15 Minh họa thuật toán phân tải Least Connections

Với Least Connections, khi mà client D kết nối sau khi A và B đã ngắt kết nối. API

GATEWAY sẽ cố gắng tạo kết nối tới KMS 1 thay vì KMS 2 ( vì KMS 2 đã có một kết nối tới

là C trong khi KMS1 chưa có kết nối nào).

Ít kết nối trọng số ( Weighted Least Connections )

Weighted Least Connections [26] là thuật tốn mở rộng của Least Connections và nó

cũng cho mỗi server một hệ số tương tự như Round Robin mở rộng ra Weighted Round

Robin.Khi API GATEWAY phân tải theo thuật toán Weighted Least Connections cần xem xét

hai thứ: trọng số/khả năng của mỗi server và số lượng kết nối hiện tại của mỗi server.

Ngẫu nhiên (Random)

Thuật toán Random [26] sẽ thực chọn ra ngẫu nhiên server kết nối. Trong trường hợp

API GATEWAY nhận một số lượng lớn kết nối, một thuật toán ngẫu nhiên sẽ cố thể phân tải

các kết nối đồng đều trên các server. Vì thế giống như Round Robin, thuật toán ngẫu nhiên là

đủ cho các server có cùng chung một cấu hình tương đương nhau (CPU,RAM…)



42



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

CHƯƠNG 3. GIẢI PHÁP PHÂN CỤM CHO KURENTO MEDIA SERVER

Tải bản đầy đủ ngay(0 tr)

×