The SaaS Migration Diaries #2: Migrating Legacy Content - Part 2
In this episode of the SaaS Migration Diaries, I share what happened when we tried running the Move Legacy Content to Content System migration tools for the first time on a development server.
If you read my earlier post you will know that before one can start trial migrations to SaaS it is necessary to migrate "Legacy Content" to the "Blackboard Xyphos Content System".
Set up
We began by setting up the tools. First we made a directory in which to host them. Blackboard support told us it mattered not where we located the files. Since /tools/admin has some similar tools I decided we would put the tools there:
And then unpack the tools:
And ensure all .sh files are executable.
Configuring the tools
Next some configuration is required. First we have to set where Java is installed:
by editing this line in the above file:
Next we have to set an Xmx setting. In this file:
The relevant line is this one:
Our approach was to stick with the default options as much as possible, we wanted to prove the tool worked, and then look at how best to tune it. If we started with tuning it before we knew if it worked we may have assumed our tuning was wrong, and I always try to keep things simple. I have enough plates I need to keep spinning at once.
So leaving the Xmx setting at the default 1GB meant we knew what we needed to do with the other settings in:
We had to:
And nothing happened. Just:
It created a pid file again:
If you read my earlier post you will know that before one can start trial migrations to SaaS it is necessary to migrate "Legacy Content" to the "Blackboard Xyphos Content System".
The process is described on Blackboard's support site. For handy reference I have made a PDF export of the instructions available.
Those who were already managed hosted have the luxury of just raising a ticket and getting Blackboard to do it.
Those of us who host locally should do this ourselves. The sooner we can migrate this legacy content, the sooner we can actually start engaging with Blackboard to trial migration to SaaS.
You can get the tools by raising a support ticket requesting them. Our approach was to then trial this on one of our small development servers, a single node VM with 16 GB RAM, 4 cores, and only ~150MB of Legacy content.
Our brill Blackboard colleague Pedro Dans had provided us with some neat SQL that would tell us how much of each content type we had:
select cm.course_id, cm.course_name, cm.available_ind as Available, nvl(trunc(cs.size_coursefiles / 1024 / 1024),0)||'MB' as Course_Files_Size, nvl(trunc(cs.size_protectedfiles / 1024 / 1024),0)||'MB' as Protected_Files_Size, nvl(trunc(cs.size_legacyfiles / 1024 / 1024),0)||'MB' as LegacyFiles_Size, nvl(trunc(cs.size_total / 1024 / 1024),0)||'MB' as Total_Size from bblearn1.COURSE_SIZE cs, bblearn1.COURSE_MAIN cm where cs.CRSMAIN_PK1 = cm.PK1 order by cs.size_legacyfiles desc
Set up
We began by setting up the tools. First we made a directory in which to host them. Blackboard support told us it mattered not where we located the files. Since /tools/admin has some similar tools I decided we would put the tools there:
mkdir /usr/local/blackboard/tools/admin/moveLegacy ; cd /usr/local/blackboard/tools/admin/moveLegacy
And then unpack the tools:
wget https://mle.southampton.ac.uk/bb/bb2020/Legacy/migration-1.1.9.zip ; unzip /usr/local/blackboard/tools/admin/moveLegacy/migration-1.1.9.zip -d /usr/local/blackboard/tools/admin/moveLegacy/; cd /usr/local/blackboard/tools/admin/moveLegacy/migration-1.1.9
And ensure all .sh files are executable.
chmod +x /usr/local/blackboard/tools/admin/moveLegacy/migration-1.1.9/*.sh
Configuring the tools
Next some configuration is required. First we have to set where Java is installed:
nano /usr/local/blackboard/tools/admin/moveLegacy/migration-1.1.9/env.sh
by editing this line in the above file:
: ${JAVA_HOME:=/usr/lib/jvm/java-1.8.0-oracle.x86_64/}
Next we have to set an Xmx setting. In this file:
nano /usr/local/blackboard/tools/admin/moveLegacy/migration-1.1.9/movecontent.sh
The relevant line is this one:
nohup $JAVA_EXEC -Xmx1024m -Dblackboard.home=$BBDIR -DXythos.RunMode=Application \
Our approach was to stick with the default options as much as possible, we wanted to prove the tool worked, and then look at how best to tune it. If we started with tuning it before we knew if it worked we may have assumed our tuning was wrong, and I always try to keep things simple. I have enough plates I need to keep spinning at once.
So leaving the Xmx setting at the default 1GB meant we knew what we needed to do with the other settings in:
nano /usr/local/blackboard/tools/admin/moveLegacy/migration-1.1.9/lib/migration.properties
We had to:
- Set “source.directory” to
/usr/local/blackboard/content/storage - Set move.thread.count by dividing the Xmx setting by 300. So 1024 / 300 means move.thread.count is 3.
- Make sure that
move.thread.countis lower than themax-pool-sizesetting for thedata-storenamedoracle-templatein/usr/local/blackboard/config/bb-datastores-standalone.xml.- If it is higher, we can edit
/usr/local/blackboard/config/bb-datastores-standalone.xmlto increase themax-pool-sizesetting (this does not require a restart or a PushConfigUpdate). - Blackboard recommend that the
max_pool_sizebe at least 10 greater thanmove.thread.count.
- If it is higher, we can edit
- So we set the max pool size to 13 and did not do a push or restart.
- The other settings were the
batch.size(default is 50) which we left at 50- the smtp host, log file and a subject header for emails.
We took a VMWare snapshot for back up, and stopped Blackboard to ensure there was plenty of memory just in case, although the tool can run while the service is up. We also ran the SQL again to be super sure how much legacy content there was.
Running the tool part 1: Audit
First we are directed to run the tool in audit mode to determine how much legacy content will be moved.
cd /usr/local/blackboard/tools/admin/moveLegacy/migration-1.1.9/; ./audit.sh --blackboard.content.home=/usr/local/blackboard/content --log.file=logs/pre-audit.log --mode=report --extended -detailed
And nothing happened. Just:
-bash-4.1$ nohup: redirecting stderr to stdout
and a blinking cursor. No CPU or database activity.
In the migration tools directory, a pidfile file is created that listed a pid of:
-bash-4.1$ more pidfile pid=7791
but
-bash-4.1$ strace -p 7791 strace: attach: ptrace(PTRACE_ATTACH, ...): No such process
as you can see above, no process with that PID was running.
No pre-audit.log was to be found any where on the server.
So after waiting 20 minutes with nothing appearing to happen, we cancelled and progressed to the next step.
Running the tool part 2: Migration
So we tried running the tool:
cd /usr/local/blackboard/tools/admin/moveLegacy/migration-1.1.9/; ./movecontent_fg.sh --all
And the following was returned.
SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/data/bb/blackboard/tools/admin/moveLegacy/migration-1.1.9/lib/slf4j-simple-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/data/bb/blackboard/systemlib/slf4j-log4j12.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [org.slf4j.impl.SimpleLoggerFactory] The HipChat settings are not valid, or missing. This feature will be disabled. The Slack settings are not valid, or missing. This feature will be disabled. 2020-03-13 11:45:28 INFO Version:37 - HCANN000001: Hibernate Commons Annotations {4.0.1.Final} 2020-03-13 11:45:28 INFO Version:41 - HHH000412: Hibernate Core {4.1.9.Final} 2020-03-13 11:45:29 INFO Environment:239 - HHH000206: hibernate.properties not found 2020-03-13 11:45:29 INFO Environment:342 - HHH000021: Bytecode provider name : javassist 2020-03-13 11:45:29 WARN ConnectionProviderInitiator:143 - HHH000181: No appropriate connection provider encountered, assuming application will be supplying connections 2020-03-13 11:45:29 INFO Dialect:123 - HHH000400: Using dialect: org.hibernate.dialect.Oracle10gDialect 2020-03-13 11:45:29 INFO LobCreatorBuilder:85 - HHH000422: Disabling contextual LOB creation as connection was null 2020-03-13 11:45:29 INFO TransactionFactoryInitiator:68 - HHH000399: Using default transaction strategy (direct JDBC transactions) 2020-03-13 11:45:29 INFO ASTQueryTranslatorFactory:48 - HHH000397: Using ASTQueryTranslatorFactory [ActiveMQ Task-1] WARN org.apache.activemq.transport.failover.FailoverTransport - Failed to connect to [] after: 10 attempt(s) continuing to retry.
We received two emails, the first saying
Beginning MoveInstallationApplication... Settings: slack.channel s3.folder all hipchat.channel s3.access_id upload.thread.count : 150 log.file : /usr/local/blackboard/logs/legacyMigration.txt slack.notify move.thread.count : 3 /usr/local/blackboard/config/service-config-move-course-content.properties smtp.subject.header : [LegMig Dev1] s3.access_key slack.webhookurl s3.bucket : blackboard.xythos.prod smtp.notify : weblearn@soton.ac.uk hipchat.access_token source.directory : /usr/local/blackboard/content/storage batch.size : 50 -S blackboard.migration.app.MoveInstallationApplication hipchat.notify limit : 600M info : true interval : 7200000 hipchat.baseurl : https://hipchat.bbpd.io/v2 -A smtp.host : localhost s3.region : us-east-1 conceal.secrets The next said MoveInstallationApplication complete [160] records processed. Duration: 00 days, 00 hours, 00 minutes, 12 seconds
The output of
/usr/local/blackboard/logs/move-course-content/move-course-content-log.txt
and
/usr/local/blackboard/logs/legacyMigration.txt
Didn't seem to have anything to concerning in it.
So it seemed like something happened at least.
Running the tool part 3: Post migration clean up
In this part we execute an audit to provide final listing of files while also purging orphaned files.
cd /usr/local/blackboard/tools/admin/moveLegacy/migration-1.1.9/; ./auditcleanup.sh --blackboard.content.home=/usr/local/blackboard/content --log.file=logs/pre-audit.log --mode=execute --extended -detailed
And nothing happened. Just:
-bash-4.1$ nohup: redirecting stderr to stdout
and a blinking cursor. No CPU or database activity.
It created a pid file again:
-rw-rw-r-- 1 bbuser bbuser 10 Mar 13 11:57 pidfile -bash-4.1$ more pidfile pid=10484 -bash-4.1$ strace -p 10484 strace: attach: ptrace(PTRACE_ATTACH, ...): No such process
It sent an email saying:
Beginning DirectoryAudit... Settings: blackboard.migration.app.DirectoryAuditApplication slack.channel s3.folder hipchat.channel s3.access_id upload.thread.count : 150 log.file : logs/pre-audit.log slack.notify move.thread.count : 3 /usr/local/blackboard/config/service-config-move-course-content.properties smtp.subject.header : [LegMig Dev1] s3.access_key slack.webhookurl s3.bucket : blackboard.xythos.prod smtp.notify : weblearn@soton.ac.uk hipchat.access_token source.directory : /usr/local/blackboard/content/storage batch.size : 50 mode : execute -S detailed extended hipchat.notify blackboard.content.home : /usr/local/blackboard/content limit : 600M info : true interval : 7200000 hipchat.baseurl : https://hipchat.bbpd.io/v2 -A smtp.host : localhost s3.region : us-east-1 conceal.secrets
and the command just ran with nothing appearing to happen. No CPU activity, no database activity, and no PID found with the id it had listed.
After an hour of no activity we did a CTRL+C
Concerning
Running the SQL query, the amount of content for Legacy Files showed exactly the same amount. Had nothing at all happened?
Next steps
So we wrote everything up and sent it and all the files and settings to Bb support. We're hoping to find out:
- How can we make the audit before and after work properly
- Did the migration actually work?
- Why does the output of the SQL query show the same amount of legacy content before and after the migration?
On the Next Episode of The SaaS Migration Diaries...
Find out what happens when we hear back from Bb support and find out whether we actually migrated any legacy content, and what we need to do next.
Comments
Post a Comment