<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    隨筆-37  評論-3271  文章-0  trackbacks-0

    WebLogic集群中多播和單播機制對比

    聲明:本站WebLogic文章將同步整理到老劉文庫.

    來源:http://allthingsmdw.blogspot.com/2012/02/multicast-vs-unicast-with-weblogic.html

    THURSDAY, FEBRUARY 9, 2012

    Multicast Vs. Unicast with WebLogic Clustering

    WebLogic Clusters manage membership via messaging within its members. The members join/leave the cluster as well as update other members via messages to the entire cluster. There are two ways for cluster messaging in WLS - Multicast or Unicast. This post goes provides a brief overview of the cluster messaging and some general guidelines around using the different messaging options.
    WLS Cluster
    WebLogic clustering provides a homogeneous model for managing a set of server instances while providing scalability, load balancing and high availability to the services running within the member instances. For the end client, it appears like one single and uniform service with all the RASP (reliability, availability, scalability, performance) capabilities. Each cluster member is aware of other members and advertise each other services in addition to their own. Refer tohttp://docs.oracle.com/cd/E11035_01/wls100/cluster/failover.html for more details on replication and failover of clustered services.
    Unicast & Multicast
    Multicast is easier to explain over Unicast. Multicast is a broadcast UDP option for sending a packet/announcement over to a group that is listening on a specific multicast address and port over which the announcement is sent.There is a defined range for valid Multicast address (224.0.0.1 to 239.255.255.255). Everyone listening on the given address hears the announcement just like following a Twitter post. Some limitations with Multicast is the TTL (time to live) across machines/subnets/routers needs to be adjusted and the routers configured to retransmit the multicast packet across subnets. More details on the weblogic specific multicast configurations can be seen in my Exalogic and Multicast blog post.
    Unicast is more of a point to point UDP option to send the packet to a specific member and not everyone. That way, unicast is more of a private conversation between two individuals while multicast is more of a shout to a group or room. Both are UDP based, so there can be losses unlike TCP that handles retransmissions on message loss. But Unicast can span across routers and does not have to worry about TTL without the everyone hearing the announcement. So, Network Admins in general prefer to go with Unicast over Multicast for these reasons.
    WLS Cluster Configuration
    When a cluster is created within a WLS Domain (either via wlst or config wizard or copy/update of existing domain), it is configured as using Unicast or Multicast messaging. As part of complete Cluster configuration, the multicast listen address and port should be specified if going with Multicast option. Also the managed servers should be targeted/added to the Cluster instance. There can be multiple clusters and any given managed server instance can only belong to atmost one cluster (or none). This will let the clustered managed servers (Admin Server should not be part of any cluster nor can cluster span domains) go with Unicast or Multicast when they are started. It should be noted that Multicast used to be the only option in WebLogic prior to 10.0 version while either Unicast or Multicast can be used from version 10 onwards.
    Cluster Messaging
    How does each member join the cluster and see or recognize others? At bootstrap time, the managed servers get their configuration via JMX MBeans from the Admin server (or from cached configurations if the Admin server was down) and recognize that they belong to a cluster and they have to go with Unicast or Multicast.
    WLS Multicast Messaging
    So, in a multicast messaging cluster, the managed servers start listening to the specified multicast address once it checks its configuration and knows it belongs to so and so cluster and has to use specified multicast address and port. Once it listens on the specified multicast address, it sends an announcement about its arrival to others via multicast - more like a shout-out. Other running clustered members of the same cluster who are already listening will respond back and add the new member to their list of known cluster members. The new member will also update its cluster list with other members. This process continues as new members get added. The membership gets renewed based on each member sending periodic announcements to other members proclaiming its liveliness. If a member goes down (shutdown or killed or not able to respond), then it wont be able to send its broadcasts and other members will drop it from the cluster list and re-add it when it comes back online. If a member is directly talking to another cluster member, just the direct socket connection is enough in establishing its membership with its connected member. Since multicast is a broadcast, just a single announcement is retain a instance's membership and let others continue to maintain it in their cluster list till its time to renew its membership. Its a mesh where every member can see every other member in the cluster.
    clip_image001
    WLS Unicast Messaging
    With Unicast, WLS divides the cluster into a multiple groups, each having a max of 10 members. The division happens as the servers come up. Each of the server listens on their specified listen address and the other members can send/receive unicast packets over that listen address as every clustered member knows the configurations of other cluster members.
    The oldest within the group is designated the group leader. The group leader communicates over Unicast to other members (over the specified member's listen address) within its group and adds/drops them based on them renewing their membership or not responding. The group leaders communicate amongst themselves. So, if there are 4 group leaders, each group having 10 servers, a membership announcement from server1 in group1 will be picked by GroupLeader1 of group1 and retransmitted to all other members within the group1 as well as to other three group leaders. The remaining group leaders will in-turn retransmit the membership information within their groups. This way, every change is picked up and retransmitted by the group leaders to within their group and to other groups via group leader to group leader communication. The group leaders remain the hub for each group while they themselves form a mesh with other group leaders.
    clip_image002
    Comparison between Unicast & Multicast

    Multicast

    Unicast

    Only option in pre-10.0 versions of WLS, continues to exist in version 10+

    Available from version 10 onwards

    Requires configurations to Routers, TTL

    No configuration required

    Requires configuring the Multicast Listen Address and port

    Just specify the listen address (can be Default Channel or use a Custom Network Channel for Cluster communication)

    One announcement to join/maintain membership

    one transmission to group leader has to be retransmitted to other group members (N) + to other group leaders (M) who then again retransmit to their group members resulting in (NxM) packets

    Everyone sees everyone

    Group Leaders have to do real heavy lifting of retransmitting every thing across its group and other group leaders and can get bogged down in just retransmitting

    Can lead to big broadcasts through the entire subnet/LAN if there are frequent joins/drops of members or change in services (JNDI updates of bound services, frequent app deployments or members going out of sync)

    Not a broadcast throughout the subnet/lan, but still more packets to be sent across as Group Leaders have to retransmit everything. Can consume bigger bandwidth

    As listed in the table above, these would be my guidelines:

    1. If the cluster is small and simple (under 20 members), go with Unicast. No configurations required and the group leaders wont be stretched retransmitting data.

    2. If the Network configurations strictly prohibit multicast and members have to reside in different subnets and cluster sizes are still under or mid-20s, go with Unicast.

    3. If its a real large cluster (over 20 members) and members can reside in the same subnet or even if they are not on same subnet but network router configurations can allow multicast, go with Multicast.

    4. If over 50 members, change to network configurations to allow multicast and stick with Multicast.

    5. Over 100 members, try to break up the domain into multiple separate domains and individual clusters for better administration and management even though Multicast option can handle such large domains. Or use custom scripts/wlst to manage and monitor individual members instead of relying on a single application (like console) to manage/monitor/handle all servers at the domain level.

    The reason for recommending Multicast over Unicast for large clusters is due to the work load on the group leaders and retransmissions. The group leaders have to retransmit every member's packet within their group as well as to other group leaders (who again send to their group members) which can just lead to more and more work as the cluster grows bigger.
    Another big reason is that WLS Multicast based messaging is quite mature and stable compared to Unicast which got only introduced with version 10. Also, with unicast, there can still be retransmits (as its not auto error correcting) and it can consume more bandwidth due to repeat retransmits by group leaders to others compared to one transmit for multicast.
    Conclusions
    I hope this article helps clarify the internal working of WLS Cluster membership around Unicast vs Multicast messaging while providing some guidance on the option to use based on requirements and constraints.

    Posted by Sabha Parameswaran at 12:33 PM

    posted on 2012-02-23 22:20 BeanSoft 閱讀(5570) 評論(0)  編輯  收藏 所屬分類: WebLogic
    主站蜘蛛池模板: 国产精品九九久久免费视频| 在线观看亚洲免费视频| 两性色午夜免费视频| 国产成人精品男人免费| 亚洲精品自偷自拍无码| 亚洲国产精品免费在线观看| 久久这里只精品99re免费| 成熟女人牲交片免费观看视频| 亚洲制服丝袜在线播放| 嫩草在线视频www免费看| 亚洲日本精品一区二区| 亚洲精品在线免费观看视频| 国产精品亚洲专区在线观看 | 亚洲精品高清一二区久久| 水蜜桃视频在线观看免费| 久久久久一级精品亚洲国产成人综合AV区 | 日本高清免费网站| 国产亚洲蜜芽精品久久| 日日噜噜噜噜夜夜爽亚洲精品 | 亚洲高清在线视频| 亚洲一级免费毛片| 亚洲综合色7777情网站777| 狼友av永久网站免费观看| 免费夜色污私人影院网站电影| 中文亚洲AV片在线观看不卡| 国产99视频精品免费专区| 久久亚洲日韩看片无码| 亚洲人成在线免费观看| 亚洲天堂中文字幕| 成人免费视频软件网站| 一级毛片在线免费视频| 日韩亚洲Av人人夜夜澡人人爽 | 99久久亚洲综合精品成人网| 亚洲一区在线免费观看| 亚洲国产精品无码第一区二区三区 | 亚洲人成网站看在线播放| 免费又黄又爽又猛的毛片| 三年在线观看免费观看完整版中文 | 免费无码成人AV在线播放不卡| 亚洲人成电影网站色www| 国产免费看插插插视频|