frankabhinav Super Contributor.
Super Contributor.
344 views

edirectory bandwidth

Hi there,

I am using edirectory 9.2 . Now I want to replicate into another edirectory.

So, what bandwidth should I keep while replication because inside edirectory doc min bandwidth and max bandwith value are missing.

Thanks:)
Labels (1)
0 Likes
2 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: edirectory bandwidth

On 03/19/2019 01:34 AM, frankabhinav wrote:
>
> I am using edirectory 9.2 . Now I want to replicate into another
> edirectory.


I am pretty sure eDirectory 9.2 is not out yet, so you may want to verify
that. If you are on it, it's probably a beta, and you should go through
the beta program. I believe eDirectory 9.1 SP3 is the latest released
patch so far (or at least the latest I see on the download site).

> So, what bandwidth should I keep while replication because inside
> edirectory doc min bandwidth and max bandwith value are missing.


I think you're actually asking about throughput, meaning the amount of
something going through something.

The throughput when adding a replica will eventually be at least as big as
the data within that partition, so if that partition is one (1) GiB in
size then you'll eventually have that much data go across the wire. When
you have no changes happen, and on background processing causing data on
the wire, there will be nothing on the wire, so the minimum is zero (0)
bytes per second and not really worth documenting. eDirectory (like
anything reasonable) doesn't use the hardware/wire unnecessarily, so there
are likely times you will see nothing out there. That does not mean you
will not see established connections among boxes, but established
connections do not cause data just by existing.

Hopefully that helps a little. If you have a big environment (GiBs of DIB
data) you may want to look at using something like DIB Clone to setup a
new server, which basically means you use a special sequence of events
within eDirectory to create a new server object and then one-time copy the
DIB over to that box using SCP or something, and then of course SCP uses
the size of that data transfer for that one-time copy.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
hendersj Acclaimed Contributor.
Acclaimed Contributor.

Re: edirectory bandwidth

On Tue, 19 Mar 2019 07:34:02 +0000, frankabhinav wrote:

> So, what bandwidth should I keep while replication because inside
> edirectory doc min bandwidth and max bandwith value are missing.


To add to ab's answer, the values aren't really 'missing' - the answer is
'it depends'.

Can you replicate over a 56K dialup connection? Sure. If your database
is large, it'll take a long time to converge, and if it changes faster
than the data can be replicated, then your directory will not converge.

The more bandwidth it has, the faster the replicas will converge. As
long as your bandwidth exceeds the rate of change in the local replicas
(which is what generates replication traffic), you'll eventually get to a
state of loose consistency - in that the data will be convergent rather
than not. In a directory that's actively used, you generally won't reach
a total state of consistency between replicas (though it is possible,
it's somewhat rare) because something's always changing, and that causes
replication to take place.

Jim

--
Jim Henderson, CNA6, CDE, CNI, LPIC-1, CLA10, CLP10
Novell/SUSE/NetIQ Knowledge Partner
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.