Deploying several hbase-rest servers in front of the HBase cluster is a way to solve the service discovery problem, as you can just use a L7 ingress to route the request to these proxies and also easy to do load balancing.
But for me, I would still suggest that we try to find a better way to solve the service discovery problem in the native java client... Thanks. 张铎(Duo Zhang) <palomino...@gmail.com> 于2024年6月13日周四 21:30写道： > > Agree, it is more like a service discovery problem. > > For performance, the official hbase java client is a rich client, > which has a built-in service discovery method, which may not work well > under some cloud environments. > > Bryan Beaudreault <bbeaudrea...@apache.org> 于2024年6月13日周四 21:19写道： > > > > We deploy kube-proxy on all of our non-kube ec2 nodes. So any client can > > still use the Services we've defined to talk to the pods. Our HMaster(s) is > > a Deployment with a Service; our NameNode(s) is a StatefulSet, and we have > > a dedicated service per namenode identifier; etc. > > > > In our hbase-site.xml, we set the bootstrap nodes to the HMaster Service. > > In our hdfs-site.xml we configure each namenode to point at the specific > > namenode service. > > > > This all works well for us, even with a mixed topology. But yea, that seems > > less about what protocol (http vs protobuf) and more about discovery. > > > > On Thu, Jun 13, 2024 at 9:08 AM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > > > > > I guess the problem is that, in some k8s setup, inside the deployment, > > > you can use the pod ips to connect to each other, that's the case for > > > communicating insde HBase cluster, like regionServerReport, etc. > > > > > > But outside the deployment, you can only access these services/pods > > > through ingress, no matter L7 or L4, you need to use a different > > > identifier. > > > > > > In our current design, there is no something like 'advertised address' > > > for all the masters and region servers in the cluster, so there is no > > > way for clients to use different identifiers when connecting the HBase > > > cluster. > > > > > > But I think for java based client, we'd better try another way to > > > support the native protocol, for better performance. > > > > > > Thanks. > > > > > > Bryan Beaudreault <bbeaudrea...@apache.org> 于2024年6月13日周四 19:38写道： > > > > > > > > Can you speak more to why HTTP would help users? > > > > > > > > We’ve been running hbase in 100% cloud environment for more than a > > > decade. > > > > We’ve never really desired an http version of the protocol. > > > > > > > > We also run more recently in a mixed kubernetes environment (master > > > > nodes > > > > in kubernetes, regionserver on dedicated ec2 nodes). In this model we’ve > > > > similarly had no real desire for http when working with services, etc. > > > > > > > > One case where it’s been useful to have http endpoint is readiness > > > checks. > > > > We’ve built a /health endpoint into the hmaster and regionserver to that > > > > end, which I plan to upstream at some point. > > > > > > > > To me creating a totally compatible http based protocol seems like a > > > > huge > > > > lift. So I’m curious what it’d really help for these cloud users. > > > > > > > > On Thu, Jun 13, 2024 at 1:07 AM Ankit Singhal <ankitsingha...@gmail.com> > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > *Context for discussion*: > > > > > > > > > > These classes were recently relocated from "src/main" to "src/test" > > > under > > > > > HBASE-24115, aligning with the original contributor's initial > > > intention of > > > > > using them only for testing. Therefore, I'm raising this in an email > > > > > to > > > > > initiate discussion with the updated information. > > > > > > > > > > At Cloudera, we've noticed a growing adoption of HBase in cloud > > > > > environments. This shift has highlighted concerns regarding network > > > > > connectivity requirements between clients and HBase regionservers, > > > > > particularly for remote clients. To address these concerns, we are > > > looking > > > > > to utilize standard web protocols such as HTTP. These protocols enable > > > > > easier integration with various cloud services by providing a single > > > > > endpoint for access and simplifying networking needs. As a result, > > > > > more > > > > > users are interested in using REST servers to meet their requirements. > > > > > Istvan has put considerable effort into testing and improving the > > > > > performance of REST servers, as seen in JIRAs like HBASE-28646, > > > > > HBASE-28613, HBASE-28626, and HBASE-28556 to achieve this target. > > > > > > > > > > *Issue*: > > > > > > > > > > However, Users with applications currently using the Java client are > > > > > encountering challenges in transitioning to REST due to the > > > > > significant > > > > > code rewriting required. By implementing the Admin and Table > > > interfaces, we > > > > > can enable these users to migrate to REST with minimal adjustments. > > > > > > > > > > *Other Protocol Implementations with Java Public APIs: * > > > > > Similar interfaces have recently been developed for Thrift under > > > > > HBASE-21661. > > > > > > > > > > *Proposed Changes:* Currently, Istvan focuses on addressing the > > > performance > > > > > and security aspects of these implementations, with efforts like > > > > > HBASE-28540 and rewriting Rest Client to support different > > > authentication > > > > > options, etc. via HBASE-28501,HBASE-28649, and HBASE-28500, which > > > > > significantly strengthened the implementation. Hence, we want to go > > > ahead > > > > > and move this implementation back to "src/main". > > > > > > > > > > Please inform us of any concerns you may have, otherwise, we would > > > like to > > > > > proceed with the PR. > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Ankit Singhal > > > > > > > >
