Tag Info

Hot answers tagged

5

Long term, this is the sort of tasks that configuration management tools (e.g., puppet, chef, ansible) are made for. For a short term solution, I'd use something like func or fabric to push out your fstab file. Going to run through an example of using fabric since that's the one I'm most familiar with. Installation depends on your distro. One of these is ...


4

No solution can be examined without knowing more about the threat model, ie, what are you trying to protect against? If you want to survive software failure on the part of your hosted image, then simply having two VMs should be fine; if one crashes, the other should still be there. If you want to survive software or hardware failure on the part of the ...


3

No, this scheme is not considered safe, because if your (provider/host server/providers backup) goes down, you won't be able to restore your business. Safest backup is when your files are going to an absolutely different location - Dropbox, S3, Github, your own home PC, etc. If any disaster happens, with this setup, you can easily buy a new server ...


1

Well as you observed, you get no failover if you put all your ColdFusion eggs in the same server basket. So if that's part of your goal, clustering multiple ColdFusion instances within one box is not going to help you. However there's still merit of sorts in having multiple CF instances serving the same app on one box: one gets multiple JVMs servicing ...


1

The Admin console doesn't need to use the Apache LB layer. You can add a DNS entry for one Apache instance for the URL, and then use this to load balance to available nodes. More common for production situations is to use a LB such as F5 or software based LB that communicates to the Apache layer, the Apache nodes can then proxy to the application server ...


1

Yes, you can do it the other way around. Just set it up like a normal synchronous cluster, but set synchronous_commit = off in postgresql.conf. Then: SET LOCAL synchronous_commit TO ON in transactions you want to commit synchronously. Keep in mind, though, that a synchronous commit will force prior commits to flush before it can commit. So if you do ...


1

If you use heartbeat 3.0.x from EPEL, then you should use crm_mon command. This will show you all the information you want: # crm_mon -1 Its output includes the number of nodes, uname, uuid, status, the resources configured in your cluster, and the current status of each. If you want to group resources by node, run a command like this: # crm_mon ...


1

Yes, it is possible if you stack the DRBD resources, meaning that you use a replicated device as physical device for another replication pair. There are a number of considerations for this though, so it might not be what you want to achieve. It's even in the docs: http://www.drbd.org/users-guide/s-three-nodes.html Also note that DRBD 9.0 (currently in ...


1

SvW nailed it, but to spell out the steps - it's pretty much like getting DRBD underneath your plain old partitions, but now the existing DRBD resource is the backing device. Assuming that the physical backing device (likely your LV) cannot be enlarged, you will need to shrink your filesystem add the stacked resource (create metadata for it) it uses ...


1

You should really be talking with your IBM partner on cases like these, as they're the best ones to answer these kind of questions. That being said - the storwize v7000 is a dual-controller system. As long as you have dual paths (you mentioned DM multipathing) to each controller then a storage processor upgrade should reboot one controller at the time, ...


1

Using a mass deployment tool like automateit, salt, puppet, ansible, etc. you could run a script (in puppet use exec) or a cronjob like below to use mount to run a mass deployed fstab: mount -a --fstab pathtofile And my old answer (if your mount is too old to have --fstab / -T): in such a mass deployment tool, you could do some terrible hackery to emulate ...


1

I agree with Peter that using a deployment tool is the neatest solution. However I disagree that mouning stuff from cron is ever a good idea! If the deployment tool is too much of a leap, I'd go with a late init/systemd script (which might fetch the definitions from a central respository) and mount the filesystems.


1

Assuming I have an admin account on each server available via SSH with public-key auth, I would simply remotely run sed or other text editing tool using this SSH account, in a bash loop.



Only top voted, non community-wiki answers of a minimum length are eligible