1 / 19

SASP v1 (Server/Application State Protocol) draft-bivens-sasp-00.txt

SASP v1 (Server/Application State Protocol) draft-bivens-sasp-00.txt. Alan Bivens jbivens@us.ibm.com IBM Research New York, USA IETF 60. SASP objectives. Provide a mechanism for workload managers to give distribution recommendations to load balancers. Must be lightweight

cedric-stout
Download Presentation

SASP v1 (Server/Application State Protocol) draft-bivens-sasp-00.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SASP v1(Server/Application State Protocol)draft-bivens-sasp-00.txt Alan Bivens jbivens@us.ibm.com IBM Research New York, USA IETF 60

  2. SASP objectives • Provide a mechanism for workload managers to give distribution recommendations to load balancers. • Must be lightweight • little implementation complexity • little processing overhead • little additional user configuration • Must be free of corporate ownership issues • Must be extendible • Control must remain at the load balancer SASP will not handle the transport or actual distribution of work, only give recommendations

  3. Example System Architecture Member Individual Workload Manager Requests Requests Request Origins Load Balancer Member Individual Workload Manager Member SASP Individual Workload Manager Group Workload Manager Protocol Characteristics SASP • Binary Streams • SSL

  4. SASP Messages • Registration Messages • DeRegistration Messages • Get Weight and Send Weight Messages • Set Member State Messages • Set LB State Messages

  5. Member C Member C 3 4 1 2 5 6 7 8 Group Workload Manager Example Flow A:(lb registration, get weights, and resource set state) • LB registers A, B, and C in GRP1. GWM replies with no error. • LB sends Get Weights message for GRP1 and receives the following: • LB sends Set LB State Message: • A sends SetMember State Message: • Resource C sends a Set Member State message to quiesce itself with the following flags: time Register A, B, C in group GRP1 Register Reply Get Weights for GRP1 Get Weights Reply Set State for LB Set State Reply Member A Set State for ResourceA Set State Reply Load Balancer Set Quiesce State ResC Set State Reply Get Weights for GRP1 Get Weights Reply Set Quiesce State ResC Set State Reply Get Weights for GRP1 Get Weights Reply

  6. 3 4 8 7 1 2 5 6 Example Flow A (continued):(lb registration, get weights, and resource set state) • LB sends the Get Weights message for GRP1 and receives the following: • Resource C sends a Set State message to un-quiesce itself with the following flags: • LB sends the Get Weights message for GRP1 and receives the following: time Register A, B, C in group GRP1 Register Reply Get Weights for GRP1 Get Weights Reply Set State for LB Set State Reply Member A Set State for ResourceA Set State Reply Load Balancer Group Workload Manager Set Quiesce State ResC Member C Set State Reply Get Weights for GRP1 Member C Get Weights Reply Set Quiesce State ResC Set State Reply Get Weights for GRP1 Get Weights Reply

  7. Only Overlap between SASP and RSERPOOL • Providing “A means for allowing flexible load assignment and balancing policies” • SASP provides a manner of doing this between two entities, but not by way of a policy.

  8. Differences between SASP and RSERPOOL • Terminology and topology: • PU -> client, outside of SASP scope • PE -> group member • ENRP Server -> some blend of load balancer and GWM • Traditional load balancing does not have such an entity • PU Proxy -> outside of SASP scope, not needed for traditional load balancing

  9. Differences cont. • Flow of protocols: • ASAP/ENRP: • PE registers with the ENRP Server • PU contacts ENRP server for PE handle resolution, and then contacts PE using designated transport protocol • SASP/Traditional load balancing: • Load balancer admin registers all group members. • Load balancer is transparent, client contacts load balancer using expected transport protocol and receives reply from initial message

  10. Current State of SASP • Multiple vendors have begun to announce support of this protocol • 2 implementations of SASP GWM components coming out in products this year. • 2 interoperating implementations of SASP Router component by two different vendors this year. • Current version of SASP available as individual ID “http://www.ietf.org/internet-drafts/draft-bivens-sasp-00.txt”

  11. What next • Should this be an informational RFC? • Would this working group like to adopt it as a standards track document? • Should we have a full BOF at the next IETF?

  12. Thank You

  13. Extra Slides • Basic Protocol Components • Group Protocol Components • Message Types

  14. Basic Protocol Components • Member State Instance • Group Data 5 Basic Components are used throughout the protocol • SASP Header • Member Data • Weight Entry

  15. Group Protocol Components • Group of Weight Data • Group of Member State Data 3 Group Components are used throughout the protocol • Group of Member Data

  16. Registration Messages • Registration • Deregistration Load Balancer SASP Resource Group Workload Manager Individual Workload Manager

  17. Weight Exchange Messages • Get Weights • Send Weights Load Balancer Fields in Weight Entry SASP Group Workload Manager

  18. Set Member State Messages • Set Member State Load Balancer Fields in Member State Instance SASP SASP Resource Group Workload Manager Individual Workload Manager

  19. Set Load Balancer State Messages • Set Load Balancer State Load Balancer SASP Group Workload Manager

More Related