Richard Megginson
2007-Jul-06 17:20 UTC
[Fedora-directory-users] Migration from 1.0 and 7.1 to 1.1
With the new FHS paths and new configuration options, there is quite a bit of stuff that has to happen to migrate old servers. The current Fedora pre-release version 1.1 has a migrateTo11 script that handles most of these, and CVS HEAD has some newer scripts to handle both directory server and admin server/console migration. We''ve created this page - http://directory.fedoraproject.org/wiki/DS_Admin_Migration - to plan our migration strategy. One of the big issues is cross platform migration e.g. going from FC-5 i386 to F7 x86_64. There are a number of issues involved with this. We are trying to figure out the best way to do this and we need your help. If you could, please read the section about cross platform migration - http://directory.fedoraproject.org/wiki/DS_Admin_Migration#Cross_platform - and let us know what you think, especially if you are an admin who will actually be using this in a production environment.
David Barker
2007-Jul-08 20:43 UTC
Re: [Fedora-directory-users] Migration from 1.0 and 7.1 to 1.1
Richard Megginson wrote:> > One of the big issues is cross platform migration e.g. going from FC-5 > i386 to F7 x86_64. There are a number of issues involved with this. > We are trying to figure out the best way to do this and we need your > help. If you could, please read the section about cross platform > migration - > http://directory.fedoraproject.org/wiki/DS_Admin_Migration#Cross_platform > - and let us know what you think, especially if you are an admin who > will actually be using this in a production environment.I''d guess the "worst-case upgrade" is a single directory server deployment where a cross platform upgrade could imply only 1 host is available for reformat? If so, doing a "Local Source to Remote Target" migration doesn''t make much sense. In such cases, an export to ldif first, backup/ reinstall / restore "/opt/fedora-ds" and then do the upgrade against the restored data seems like the best way to do things. Multi-directory-server sites probably have spare hardware kicking around - I wouldn''t worry about wasting disk space ;-)
Richard Megginson
2007-Jul-09 14:38 UTC
Re: [Fedora-directory-users] Migration from 1.0 and 7.1 to 1.1
David Barker wrote:> Richard Megginson wrote: >> >> One of the big issues is cross platform migration e.g. going from >> FC-5 i386 to F7 x86_64. There are a number of issues involved with >> this. We are trying to figure out the best way to do this and we >> need your help. If you could, please read the section about cross >> platform migration - >> http://directory.fedoraproject.org/wiki/DS_Admin_Migration#Cross_platform >> - and let us know what you think, especially if you are an admin who >> will actually be using this in a production environment. > > I''d guess the "worst-case upgrade" is a single directory server > deployment where a cross platform upgrade could imply only 1 host is > available for reformat? If so, doing a "Local Source to Remote Target" > migration doesn''t make much sense. In such cases, an export to ldif > first, backup/ reinstall / restore "/opt/fedora-ds" and then do the > upgrade against the restored data seems like the best way to do things.Do you mean, you reformat the disk and install the new version of the OS? On the same machine? In that case, if the architecture is the same, no data conversion is needed - the data in the databases can just be used directly.> > Multi-directory-server sites probably have spare hardware kicking > around - I wouldn''t worry about wasting disk space ;-)Sure, but there are some cases where folks will have multi-GB databases on old machines.> > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users
Eddie C
2007-Jul-09 15:33 UTC
Re: [Fedora-directory-users] Migration from 1.0 and 7.1 to 1.1
I will tell a little about how we handled are cutover from iplanet 5.2running on SPARC hardware to FC5 on x86-64. I had some extra ports on our terminal server so I connected the old SPARC systems to the terminal server so I can manage them out-of-band (and later after I took their IP addresses away) Remember LDAP is a directory service. Directory services support frequent read operations and infrequent write operations. Not every application fits this profile but in our case we shut down/disabled our web application that modifies our LDAP. We have a multi-GB database approx 2 GB. We ran an LDAP search command/db2ldif. I do not remember this taking a long time probably < 8 minutes. Remember LDAPsearch is very fast. We were moving from master/slave to multi-master. At that point I setup multi-master on the new systems. We used SCP to copy over the ldif data, then I added it to one side using Ldapmodify. Again this took less then 20 minutes. I quickly re-added indexes and verified final settings. Then I disabled the old systems using the Terminal Server and added a sub-ip-interface to the new systems for an IP take-over. When we had done testing and all was well and good again we re-enabled out web application. For us the migration was a Friday process and our window was based on how long we could live without database changes. All our applications that have read access suffered a small intermittent outage when we switched the IP. The good part about this process is you can completely test the dump and restore without doing the actual cut-over to see how long the entire process will take. Dump from your old harware/restore to new. Tools to move the database real time/cross platform would be nice, but in our case they would be overkill if you have a small amount of data the standard tools can probably do it in soft-real time. On 7/9/07, Richard Megginson <rmeggins@redhat.com> wrote:> > David Barker wrote: > > Richard Megginson wrote: > >> > >> One of the big issues is cross platform migration e.g. going from > >> FC-5 i386 to F7 x86_64. There are a number of issues involved with > >> this. We are trying to figure out the best way to do this and we > >> need your help. If you could, please read the section about cross > >> platform migration - > >> > http://directory.fedoraproject.org/wiki/DS_Admin_Migration#Cross_platform > >> - and let us know what you think, especially if you are an admin who > >> will actually be using this in a production environment. > > > > I''d guess the "worst-case upgrade" is a single directory server > > deployment where a cross platform upgrade could imply only 1 host is > > available for reformat? If so, doing a "Local Source to Remote Target" > > migration doesn''t make much sense. In such cases, an export to ldif > > first, backup/ reinstall / restore "/opt/fedora-ds" and then do the > > upgrade against the restored data seems like the best way to do things. > Do you mean, you reformat the disk and install the new version of the > OS? On the same machine? In that case, if the architecture is the > same, no data conversion is needed - the data in the databases can just > be used directly. > > > > Multi-directory-server sites probably have spare hardware kicking > > around - I wouldn''t worry about wasting disk space ;-) > Sure, but there are some cases where folks will have multi-GB databases > on old machines. > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > >
Richard Megginson
2007-Jul-09 15:41 UTC
Re: [Fedora-directory-users] Migration from 1.0 and 7.1 to 1.1
Eddie C wrote:> I will tell a little about how we handled are cutover from iplanet 5.2 > running on SPARC hardware to FC5 on x86-64.This is very good information. Thanks!> > I had some extra ports on our terminal server so I connected the old > SPARC systems to the terminal server so I can manage them out-of-band > (and later after I took their IP addresses away) > > Remember LDAP is a directory service. Directory services support > frequent read operations and infrequent write operations. Not every > application fits this profile but in our case we shut down/disabled > our web application that modifies our LDAP. > > We have a multi-GB database approx 2 GB. We ran an LDAP search > command/db2ldif. I do not remember this taking a long time probably < > 8 minutes. Remember LDAPsearch is very fast.db2ldif is much, much faster than ldapsearch.> > We were moving from master/slave to multi-master. At that point I > setup multi-master on the new systems. We used SCP to copy over the > ldif data, then I added it to one side using Ldapmodify. Again this > took less then 20 minutes.ldif2db is much, much faster than ldapmodify.> > I quickly re-added indexes and verified final settings. Then I > disabled the old systems using the Terminal Server and added a > sub-ip-interface to the new systems for an IP take-over. > > When we had done testing and all was well and good again we re-enabled > out web application. > > For us the migration was a Friday process and our window was based on > how long we could live without database changes. All our applications > that have read access suffered a small intermittent outage when we > switched the IP. > > The good part about this process is you can completely test the dump > and restore without doing the actual cut-over to see how long the > entire process will take. Dump from your old harware/restore to new. > > Tools to move the database real time/cross platform would be nice, but > in our case they would be overkill if you have a small amount of data > the standard tools can probably do it in soft-real time. > > > On 7/9/07, *Richard Megginson* <rmeggins@redhat.com > <mailto:rmeggins@redhat.com>> wrote: > > David Barker wrote: > > Richard Megginson wrote: > >> > >> One of the big issues is cross platform migration e.g. going from > >> FC-5 i386 to F7 x86_64. There are a number of issues involved > with > >> this. We are trying to figure out the best way to do this and we > >> need your help. If you could, please read the section about cross > >> platform migration - > >> > http://directory.fedoraproject.org/wiki/DS_Admin_Migration#Cross_platform > >> - and let us know what you think, especially if you are an > admin who > >> will actually be using this in a production environment. > > > > I''d guess the "worst-case upgrade" is a single directory server > > deployment where a cross platform upgrade could imply only 1 host is > > available for reformat? If so, doing a "Local Source to Remote > Target" > > migration doesn''t make much sense. In such cases, an export to ldif > > first, backup/ reinstall / restore "/opt/fedora-ds" and then do the > > upgrade against the restored data seems like the best way to do > things. > Do you mean, you reformat the disk and install the new version of the > OS? On the same machine? In that case, if the architecture is the > same, no data conversion is needed - the data in the databases can > just > be used directly. > > > > Multi-directory-server sites probably have spare hardware kicking > > around - I wouldn''t worry about wasting disk space ;-) > Sure, but there are some cases where folks will have multi-GB > databases > on old machines. > > > > -- > > Fedora-directory-users mailing list > > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > <mailto:Fedora-directory-users@redhat.com> > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >