190 likes | 205 Views
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
E N D
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 • 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
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
SASP Messages • Registration Messages • DeRegistration Messages • Get Weight and Send Weight Messages • Set Member State Messages • Set LB State Messages
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
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
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.
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
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
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”
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?
Extra Slides • Basic Protocol Components • Group Protocol Components • Message Types
Basic Protocol Components • Member State Instance • Group Data 5 Basic Components are used throughout the protocol • SASP Header • Member Data • Weight Entry
Group Protocol Components • Group of Weight Data • Group of Member State Data 3 Group Components are used throughout the protocol • Group of Member Data
Registration Messages • Registration • Deregistration Load Balancer SASP Resource Group Workload Manager Individual Workload Manager
Weight Exchange Messages • Get Weights • Send Weights Load Balancer Fields in Weight Entry SASP Group Workload Manager
Set Member State Messages • Set Member State Load Balancer Fields in Member State Instance SASP SASP Resource Group Workload Manager Individual Workload Manager
Set Load Balancer State Messages • Set Load Balancer State Load Balancer SASP Group Workload Manager