I am using Openshift and installed Tomcat 7 (JBoss EWS 2.0) and Mysql 5.5, Jenkins and PHPMyadmin. i am using free version which is basically small gears. Actually i am facing difficulty in uploading my war file every now and then. then i have to clean up the space only then it will allow me to deploy the war file.
My question is that is it the case of small gears or something else. Going for a paid plan can solve my plan or not.
Between, my application is small (30MB War) plus small DB.
Please respond
The free account gives you three gears each with 1GB of disk space. Your application gear is hosting Tomcat, MySQL, and PHPMyAdmin cartridges so they will consume the disk space. Also, if you are storing multiple deployments than they all will consume space. Can you check the disk quota of your application? SSH into the application gear and run quota -s command. The paid plan offering will solve this problem because you can get more storage upto 6GB per gear. You can run rhc tidy command to clean out your gear as well.
Related
i have opensfhit account and i am setting up my application which required more space than 1GB. as stated in this link , each gear has 1GB memory space.
and maximum of 3 gears allowed. is it possible to combine 3 Gears into 1 Gear which can have 3GB of space. currently i am in free plan, and having 1 gear with 1GB space, which has two cartridges Jboss and Postgresql database. Both combined is taking more than 1GB. so i cant deploy the application due to space constraint.. any direction would really help me.
Edit :-
I have created the scaled application in free plan, and as per openshift document, each gear can max hold 1GB space, and in my case , 2 Jboss (scaled) , load balancer, 1 psql database, so one gear will have(Jboss + load balancer) combined 1GB, 2nd gear postgresql 1GB space, and 3rd gear Jboss 1GB (scaleable).
Note :- in above case, minimal allowable gears to scale will be 2 and not 3, since one gear already allocated to database. But maximum allowed gears are 3 for scalling, and i don't know how it works.
From openshift admin panel -
JBoss Application Server 7 using 2
OpenShift is configured to scale this cartridge with the web proxy
HAProxy. OpenShift monitors the incoming web traffic to your
application and automatically adds or removes copies of your cartridge
(each running on their own gears) to serve requests as needed.
Control the number of gears OpenShift will use for your cartridge:
Minimum 2 (dropdown) and Maximum 3 (dropdown) small gears
Each scaled gear is created the same way - the normal post, pre, and
deploy hooks are executed. Each cartridge will have its own copy of
runtime data, so be sure to use a database if you need to share data
across your web cartridges.
If you deploy as a scaled application then the database would reside on a separate gear from your JBoss application, so the database would have 1GB of disk space all to itself. So you would basically have 1GB for your DB, and 1GB for JBoss. If that isn't enough then you would have to upgrade to a paid plan in order to have more disk space available on an individual gear.
I ran into the same issue and found that this was not well documented or at least not intuitively described, since 3*1GB initially seems to imply that you might just have 3GB total disk space, which is not quite the case.
Here is a quote from the documentation on scalable applications (if it is not scalable you only have 1 Gear anyways):
The HAProxy cartridge sits between your application and the public internet and routes web traffic to your web cartridges. When traffic increases, HAProxy notifies the OpenShift servers that it needs additional capacity. OpenShift checks that you have a free gear (out of your remaining account gears) and then creates another copy of your web cartridge on that new gear. The code in the git repository is copied to each new gear, but the data directory begins empty. When the new cartridge copy starts it will invoke your build hooks and then the HAProxy will begin routing web requests to it. If you push a code change to your web application all of the running gears will get that update.
Source: https://developers.openshift.com/en/managing-scaling.html (in section "How Scaling Works"
To summarise: GIT data is copied across all gears, so you have 3 times 1GB of the identical GIT data. #mbaird pointed out that this is not true for user data, which is not replicated. Also, depending on your cartridge, in a scaled application your database might be on a separate gear.
For static content hosting it seems like that if you need more disk space or INodes you have to change to a different plan or spread your data across multiple applications.
From what I gather, the only way to use a MySQL database with Azure websites is to use Cleardb but can I install MySQL on VMs provided in Azure Cloud Services. And if so how?
This question might get closed and moved to ServerFault (where it really belongs). That said: ClearDB provides MySQL-as-a-Service in Azure. It has nothing to do with what you can install in your own Virtual Machines. You can absolutely do a VM-based MySQL install (or any other database engine that you can install on Linux or Windows). In fact, the Azure portal even has a tutorial for a MySQL installation on OpenSUSE.
If you're referring to installing in web/worker roles: This simply isn't a good fit for database engines, due to:
the need to completely script/automate the install with zero interaction (which might take a long time). This includes all necessary software being downloaded/installed to the vm images every time a new instance is spun up.
the likely inability for a database cluster to cope with arbitrary scale-out (the typical use case for web/worker roles). Database clusters may or may not work well when a scale-out occurs (adding an additional vm). Same thing when scaling in (removing a vm).
less-optimal attached-storage configuration
inability to use Linux VMs
So, assuming you're still ok with Virtual Machines (vs stateless Cloud Service vm's): You'll need to carefully plan your deployment, with decisions such as:
Distro (Ubuntu, CentOS, etc). Azure-supported Linux distro list here
Selecting proper VM size (the DS series provide SSD attached disk support; the G series scale to 448GB RAM)
Azure Storage attached disks being non-Premium or Premium (premium disks are SSD-backed, durable disks scaling to 1TB/5000 IOPS per disk, up to 32 disks per VM depending on VM size)
Virtual network configuration (for multi-node cluster)
Accessibility of database cluster (whether your app is in the vnet or accesses it through a public endpoint; and if the latter, setting up ACL's)
Backup / HA / DR planning
Someone else mentioned using a pre-built VM image from VM Depot. Just realize that, if you go that route, you're relying on someone else to configure the database engine install for you. This may or may not be optimal for what you're trying to achieve. And the images may or may not be up-to-date with the latest versions, patches, etc.
Of course, what I wrote applies to any database engine you install in your own virtual machines, where a service provider (such as ClearDB) tends to take care of most of these things for you.
If you are talking about standard VMs then you can use a pre-built images on VMDepot for that.
If you are talking about web or worker roles (PaaS) I wouldn't recommend it, but if you really want to you could. You would need to fully script the install of the solution on the host. The only downside (and it's a big one) you would have would be the that the host will be moved to a new host at some point which would mean your MySQL data files would be lost - if you backed up frequently and were happy to lose some data then this option may work for you.
I think, that the main question is "what You want to achieve?". As I see, You want to use PaaS solution with Web Apps or Cloud Service and You need a MySQL database. If Yes, You have two options (both technically as David Makogon said). First one is to deploy Your own (one) server with MySQL and connect to it from the outside (internet side). Second solution is to create one MySQL server or cluster and connect Your application internally in Azure virtual network. WIth Cloud Service it is simple but with Web App it is not. You must create VPN gateway in Azure VM and connect Your Web App to this gateway. In this way You will have internal connection wfrom Your application to Your own MySQL cluster.
I have checked almost all solutions both in Openshift forum and here in stackoverflow but couldn't solve the problem.
Here is the situation
I have a php server with load balancing in one gear.
I have a second gear for mysql server along with PhpMyAdmin. At present OpenShift does not support load balancing for PhpMyAdmin, so my second gear does not have any scaling feature.
Now I want to host a php app in first gear and the database in the second gear. So how do I connect them internally (would be better if I could do it without port forwarding)? I need all the commands from the beginning to the end unfortunately.
Thank you.
You should just add the mysql cartridge to your scaled application. It will still put the mysql database on it's own gear, but it will be accessible from your scaled application using the standard mysql environment variables. You can view those variables by sshing into your application and running env | grep mysql. If you decide to run your own second gear for the mysql database (you still had to install a web cartridge anyways to do that right?) then you will either HAVE to use port forwarding for direct access, or you will have to write an API on that server that will allow your application to access the mysql database.
I have a cluster of five virtual machines (with KVM hypervisor), and I want to find the best way to integrate HDFS in order to optimize storage management of Data.
Since HDFS is a distributed file system that can allows client to access in parallel to a file, I want to take advantage of this feature.
So, it is possible to install HDFS in the cluster to manage the disk space of VMs or to integrate it in OpenShift to manage data of PaaS end user?
If you are thinking of using this with OpenShift Origin or OpenShift Enterprise then you can just expose the HDFS to the OpenShift nodes as a user disk space and they can use it. Remember when you install OpenShift on your own infrastructure you can expose any file system you want as long as you can normally do it for Linux users.
We have a Java EE application (EAR file deployed on JBoss, MySQL, MongoDB) which we would like to deploy on an Amazon EC2 instance. I have several questions regarding deployment best practices.
What is the most commonly used Linux AMI which we can rely on for a robust deployment (There are so many Linux variants, and I am not sure which AMI is commonly used, is it Fedora, CentOS, Red Hat, SUSE ...)
How do we handle production upgrades (EAR file modifications or schema upgrades). Are there any tools which are available to handle this installation or rollback of these changes.
What kind of data backup capability is available for the database?
Should I rely on Amazon RDS for MySQL support?
How should I handle support for MongoDB?
This is the first time, I am hosting an web-app and would appreciate some inputs on how to manage the production instance.
I agree with Mark Robinson's answer: Use whichever Unix variant you're most comfortable with. It may pay to pick one with decent cloud support. For my site I use Ubuntu.
I have a common image which is the base of every version deploy I do. I have www.mysite.com pointing to an Elastic IP so I can decide which instance it goes to. The common image has all the software I need installed (Postgres/Postgis/Tomcat/etc) but the database and web server data folders and symlinked to Elastic Block Store (EBS) instances.
When it comes time to do a deploy I start a new instance up, freeze and snapshot the EBS volumes on production and make new volumes. I point my new instance at the new volumes and then install whatever I need to onto that. Once I've smoke tested everything successfully I can switch the Elastic IP to point to the new instance and everything keeps on going.
I'll note that I currently have the advantage where only I can modify the database; no users can. This will become a problem shortly.
If you use the XFS filesystem on top of the EBS volume then you can tell XFS to freeze the file system (so no updates happen) then call the EC2 api to snapshot the volume then unfreeze the file system. The result is that the snapshot is taken quickly and sent to S3. I have a nightly script which does this.
If RDS looks like it will suit your needs then use it. Amazon is building lots of solid tools quickly and this will ease your scalability issues if you have any.
I'm sorry, I have no idea.
Good question!
1) I would recommend going with whatever Linux variant you are most comfortable with. If you have someone who is really keen on CentOS, go with that. Once you have selected your AMI, take it and customize it by configuring how you want it. Then save that AMI as you base-layout. It will make rolling out new machines much easier and save your bacon if EC2 goes down.
2) Upgrades with EC2 can be tres cool. Instead of upgrading a live system, take your pre-configured AMI, update that and save that AMI as myAMI-1.1 (or whatever). That way, you can flip over to the new system almost instantly AND roll back to a previous version in case something breaks. You can also back-up DB instances to S3. It's cheap at about $0.10/GB/Month.
3) It depends where you are storing your DB. If you are storing it on your EC2 instance you are in trouble. The EC2 instances have no persistence storage. So if your machine crashes, you lose everything. I'm not familiar with Amazon DB system but you should also look into Elastic Block Store. It's basically an actual hard-drive you can write to. When you want to upgrade your schema, do a full DB dump to S3 and then do an upgrade of your actual schema. If something goes wrong, you can pull the previous version out of S3.
4) & 5) I have never used those so I can't help you.
What is the most commonly used Linux AMI which we can rely on for a robust deployment (There are so many Linux variants, and I am not sure which AMI is commonly used, is it Fedora, CentOS, Red Hat, SUSE ...)
How do we handle production upgrades (EAR file modifications or schema upgrades). Are there any tools which are available to handle this installation or rollback of these changes.
What kind of data backup capability is available for the database?
Should I rely on Amazon RDS for MySQL support?
How should I handle support for MongoDB?
Any Linux AMI will do the job, what you need is a JRE only. (assuming development work not required). If you need to monitor the JVM behavior then get JConsole installed.
Easiest and painless way is to SSH into the local home directory, transfer the updated class file/EAR file (depends the number of changes applied) and copy and replace into the Tomcat deployment directory, restart apache. (make sure you tested locally before upload to production).
Depends on which database you are using, if you are using MySQL then just do scheduled backup that writes to your home directory so that from time to time you could SSH in and download a copy for backup purpose.
I would not consider reply on Amazon RDS for MySQL support due to 2 reasons: MySQL is small enough and manageable, and also I would want to have total complete control of the database and why pay for more when you can do it yourself FOC?
The usage of MongoDB should be align with the purpose of your application and benefits you gain from that. I would recommend you use MongoDB for static data retrieval like state, country, area etc... where MySQL to be use for transaction data only.
If you can live with deploying your Java EE application on TomEE instead of JBoss, Boxfuse does what you want.
For you Java EE application you literally only have to execute (TomEE uses war files instead of ear files):
boxfuse run my-tomee-app-1.0.war -env=prod
This will
Create AMI containing TomEE and your application ready to boot
Create an Elastic IP or ELB
Create a security group with the correct ports defined
Create an auto-scaling group
Launch your instance(s)
Any subsequent update will be done as a zero downtime blue/green deployment.
More info: https://boxfuse.com/blog/javaee-aws