Rino Razzi's picture
Rino Razzi - Fri, 2016/01/22 - 20:17

Hello.
I need to move an old server with a TYPO3 Appliance based on TurnKey 12.0 from the current M1.small instance on turnkey Hub  (M1.small EBS-backed PVM - 1.7 GB RAM, 1 vCPU, 80G rootfs, 160 GB tmp)
to a new instance T2.medium.
I can't do it using "clone a new server from latest snapshot" because the T2.medium instance is not in the list of available instances to chooose.

I have already tried in a different way:

1. Launched new server based on current Typo3 Appliance and  T2.medium instance.
2. used TKLBAM from the new server to restore a full backup of current server based on  TurnKey 12.0 from the current M1.small

The problem is thata when I launch TKLBAM I receive an error and the restore don't run.

In any case I realized that even if I succeed on restoring old server on new instance on the new server I have new versions of PHP, MYSQL etc...

This means I have to  upgrade my TYPO3 version (and other php - mysql apps too).

This requires too much works.

Then, my question is:

is there a way to install an old turnkey appliance (TYPO3 Appliance - TurnKey 12.0) on TurnKey Hub?

Thanks in advance for any idea

Rino

Forum: 
Support
Tags: 
typo3
Jeremy Davis's picture

Jeremy Davis - Sat, 2016/01/23 - 02:08
According to this thread a TYPO3 migration to v13.0 should work fine (the bugs with TKLBAM noted in that thread should be long resolved).

To add weight to my suggestion of updating (at least to v13.0), keep in mind that Debian Squeeze (what v12.0 was based on) is about to reach EOL (less than a month). After that it will no longer get security updates. So having that live on the internet will be a bad idea; especially on Amazon (or any other large hosting firm) as their IPs are often targeted by attackers looking for vulnerabilities.

So I recommend that you try doing a TKLBAM migration to v13.0, that will give you about 2 more years of OS level security updates (old version of TYPO3 itself may have security issues).

Keep in mind that only the v14.0+ versions are available for the newer (relatively cheaper from what I've heard) AWS server sizes. The new sizes require a differently built AMI that we did not produce for v13.0 and won't be backporting.

If you anticipate wanting your server running beyond the next 2 years then I suggest that you look at doing the upgrade to v14.0 asap. It will possibly save you money and will give you OS security updates until early 2020. Actually you may even find that you can do the TYPO3 version upgrade on v13.0; then use TKLBAM to migrate that to v14.0?!

[update] Oops, I just realised that you specifically wanted a t2.medium. To make v12.0 run on t2.medium you would need to build your own AMI somehow. That would be much more work than updating TYPO3 IMO.

Rino Razzi's picture

Rino Razzi - Fri, 2016/01/29 - 19:01

Hi Jeremy and thanks for your replay.

Yes, I know: i should have upgraded at list to TurnKey 13 for security reasons... 

But I can't do it now because this requires upgrading of TYPO3 and other web apps.

I'll do it as soon as I can.

For now I decided to move the old m1.small to a new m1.medium instance.

I did it as follow:

1. createa a snapshot of old m1.small

2. created a new server on M1.medium instance with  "Clone a new server from latest snapshot" 

3. lauched the new server

The new server was running with seemingly non problem.

But today  noticed that the new server has not swap disk configured.

Here is what I see with a "top" command:

swap: 0k total  , 0k used, 0k free

I checked the old server: the swap disk was ok there.

Do you know how to fix this the problem?

Rino Razzi

Archimede Informatica

Pisa, Italy

Jeremy Davis's picture

Jeremy Davis - Sat, 2016/01/30 - 02:24
But according to Amazon it does have 410GB instance store so you could mount that (if it's not already mounted) and create a swap file on it. Although Linux generally uses a swap partition, it can use a file too.

So the first thing to do is see what you have and where they are. Traditionally I have always used fdisk -l for that but I recently discovered lsblk which gives a nicer layout IMO.

I don't have access to a m1.medium ATM so I'm not sure what it'll be but my guess is that it'd be /dev/xvda2. If it's not mounted already (possibly already mounted to /mnt) you'll need to mount it somewhere. /mnt is as good a place as anywhere. So assuming that my guesses are right, do something like this (adjust as necessary if I am wrong). 

mount /dev/xvda2 /mnt

Then create an empty file, make it secure and make it swap. Again adjust if need be (this will create 2GB swap file). 

dd if=/dev/zero of=/mnt/swapfile bs=1M count=2048
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile

To ensure that it remounts after reboot, you'll also want to add an entry (or 2) to your /etc/fstab. Something like this (the first line might already exist as per comments above; adjust as need be). 

/dev/xvda2    /mnt    auto    defaults,nobootwait 0   2
/mnt/swapfile swap    swap    defaults            0   0
Then mount the swap file (as per fstab entries): 
swapon -a

FWIW if it didn't have instance store (as per the newer t2 instances) then you would have to decide if you really need swap, or whether you'd be better upgrading to an instance with more RAM. As you pay for excessive i/o operations on EBS volumes (i/o on instance storage isn't charged by AWS), a heavily used swap could turn out to be quite expensive...

Rino Razzi's picture

Rino Razzi - Sat, 2016/01/30 - 04:22

I have found on AWS documentation that swap volumes are included by default only for instances with low RAM (m1.small, c1.medium). So, you are right about that, m1.small don't have a swap volume.

I created a swap file on the instance store as suggested by you.

It works fine but I have an other question:

as for AWS documentation, data on instance store volume is lost when the instances are stopped

(http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html#...)

So, in such a case, do I have re-create the swap file by hand?

Or may be is there a way to automatically create it at boot time of the instance.?

Thanks again for your help.

Rino Razzi

Archimede Informatica

Pisa, Italy

Jeremy Davis's picture

Jeremy Davis - Sat, 2016/01/30 - 08:22
Silly me, that didn't even occur to me...

Adding it to fstab isn't enough... You'd actually have to recreate the swap file on every boot...

In that case it's probably better to remove the swap fstab entry and have a script that runs on boot to recreate the swap file and enables it.

You could either write a service to do that (i.e. the service checks for the swap file, if not there creates it, turns swap on and exits). Or a cron job...

Rino Razzi's picture

Rino Razzi - Mon, 2016/02/01 - 16:24

An other solution could be to put  the swap file on the root partition ( / ).

I have enought disk space to do it.

In such a case  the problem will be backup:

every time tklbam does an incremental backup the full swap file (4GB) will be backed up becouse the file will result different from previous day.

Isn't it?

So I think I'll try using a script who runs at any boot to create and mount the swap file.

Rino Razzi

Archimede Informatica

Pisa, Italy

Jeremy Davis's picture

Jeremy Davis - Tue, 2016/02/02 - 10:04
Amazon don't charge for I/O on ephemeral storage so mounting your swap there is ideal cost wise. On the other hand I have read that ephemeral storage can be quite slow so a swap there may not be great. TBH I have never run a swap file on an EBS volume but I imagine that it could get quite expensive if it is swapping lots.

Unless it's only occasionally swapping you may actually be better off just going for a larger server (with more RAM) than using a swap on your EBS volume. It will certainly run much better.

Although FWIW while trying to find some info on what the I/O costs might be, it seems that there is no additional I/O costs on SSD drives. If you want higher IOPS then you payu extra for the high IOPS SSD. It seems that the I/O is only charged separately when using Magnetic EBS volumes. Have a look here and see if you agree with the way that I'm reading it...

Also AFAIK the Hub will provision SSD EBS volumes by default. Regardless it would pay to double check that in the AWS console IMO.

WRT TKLBAM, you are right, although adding an exclusion to the tklbam.conf is really easy. Have a loog at the TKLBAM docs.

Add new comment