hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manthosh Kumar T <manth...@gmail.com>
Subject Re: Geographically distant client
Date Thu, 03 Apr 2014 13:57:42 GMT
Is that a good idea even if I don't have a VPN??. Will it be efficient in a
fairly good connection?


On 3 April 2014 19:25, Jean-Marc Spaggiari <jean-marc@spaggiari.org> wrote:

> I will say, remote client connecting to a cluster is fine. But a cluster
> spread over multiple physical sites is not at all a good idea.
>
>
> 2014-04-03 9:28 GMT-04:00 Manthosh Kumar T <manthosh@gmail.com>:
>
> > Pardon me if I miss anything, like any network issues
> >
> >
> > On 3 April 2014 18:57, Manthosh Kumar T <manthosh@gmail.com> wrote:
> >
> > > I mean directly interacting with the remote zookeeper. Say I'm able to
> > > access the zk server and hbase server externally.
> > >
> > >
> > > On 3 April 2014 18:54, Ted Yu <yuzhihong@gmail.com> wrote:
> > >
> > >> Regions hosted by the server may be moved to other servers.
> > >>
> > >> Can you clarify what you meant by directly writing to the server ?
> > >>
> > >> Thanks
> > >>
> > >> On Apr 3, 2014, at 5:59 AM, Manthosh Kumar T <manthosh@gmail.com>
> > wrote:
> > >>
> > >> > Hi All,
> > >> >         I have around 20-30 geographically distant clients that need
> > to
> > >> > write data to a centralized HBase server. I have dedicated VPN for
> the
> > >> > communication and hence bandwidth won't be a issue. is it a good
> idea
> > to
> > >> > make the clients directly send data to the centralized server?. Or
a
> > >> > geographically distributed Hadoop cluster is more efficient for this
> > >> > scenario? Has anybody come across such use case?. Need suggestions
> on
> > >> the
> > >> > viability and efficiency of the setup to follow
> > >> >
> > >> > --
> > >> > Cheers,
> > >> > Manthosh Kumar. T
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Manthosh Kumar. T
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Manthosh Kumar. T
> >
>



-- 
Cheers,
Manthosh Kumar. T

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message