Oracle Grid Support

[markbmorgan]

We're looking at using AppLogic to support a vertical application, where we're going to need to use Oracle RAC. In order to do this, I need a storage appliance that can run OCFS. But, that's not one of the "stock" file system types, of course.

Is this even going to be possible? I could put a volume out there with no FS, and have the appliance init it, but then persistence is gone, if the appliance gets restarted, so that's not a solution.

Will Oracle allow the use of the FS without licenses? Without this support, we're not going to be able to use AppLogic for our system.

Any ideas?

[nobu]

Honestly, I'm not sure about that, and I'll ask someone to answer your question.

[PeterNic]

In order to do this, I need a storage appliance that can run OCFS. But, that's not one of the "stock" file system types, of course.

Is this even going to be possible? I could put a volume out there with no FS, and have the appliance init it, but then persistence is gone, if the appliance gets restarted, so that's not a solution.


Mark, you can put any filesystem in an appliance. In this case, you can, for example, install OCFS on the Oracle appliance, or on a separate storage appliance. You will have to compile the OCFS kernel module for the kernel used in the appliance (we provide the kernel sources; who hosts your grid?). If anyone is using it under Xen (which we use for VMs), then it will work under AppLogic as well.

The way the custom FS works is by being on an application volume (aka placeholder). For example, we built a storage appliance, similar to our stock NAS appliance (http://doc.3tera.net/AppLogic1/CatMiscNas.html), and put reiserfs on the data volume.

The only thing you'll have to do in the appliance is format the volume the first time -- once it is formatted, it will not be formatted again, so all data will remain persistent. We are using a similar approach in the MYSQL appliance, which initializes the database if it finds that the volume doesn't have a database (http://doc.3tera.net/AppLogic1/CatMiscMySQL.html)

Reading Oracle's site, Oracle may not provide support for such installations; if this is important for you, you should check with Oracle. Now that RHEL and SuSE include Xen, Oracle may already have an RPM and/or provide support for virtual machines running OCFS.


Will Oracle allow the use of the FS without licenses? Without this support, we're not going to be able to use AppLogic for our system.
Any ideas?
OCFS is open source and free. Oracle distributes OCFS under the GPL license -- see http://oss.oracle.com/projects/ocfs/. I take this to mean it works without requiring special licensing (of course, the Oracle database server itself will probably require a license)

Regards,
-- Peter

[markbmorgan]

Hi Peter -

Thanks for the thorough response!

We're using layered technologies at the moment. Have any links as to any special considerations in building kernels under AppLogic?

Thanks!

[nobu]

Hi, I'm asking Peter about this.
(Availability of How-to, source code, etc.)


I know Layered has a link to the source code in their forum.
http://layer0.layeredtech.com/showthread.php?t=4995

But I'm not sure if it's the right one for the version of AppLogic you are using.

Anyway, stay tuned for more info.

[PeterNic]

Mark, sorry for the delayed response. The kernel posted at Layered's support forum is the correct one and will work for appliances under AppLogic up to and including version 1.2.14b. If you have any problems with getting OCFS compiled, please post here again.

[markbmorgan]

Peter -

Thanks for the info! I'll do the build this weekend and let you know how it comes out. Would you recommend starting with the singleton linux appliance, or the Centos machine?

[PeterNic]

A branched LINUX appliance will be easier, if Fedora Core 3 is an acceptable OS to run the Oracle on. You can connect the 'net' output terminal of the appliance to a NET gateway and this will give you access to the Internet from within the appliance (makes downloads easier; make sure you give it plenty of memory, too).

If you prefer to use one of the CentOS bases (GSC from AppLogic or GridLayer), please make sure the arp_ignore is set to 1 in the network config file before adding any terminals; otherwise the appliance will experience network problems. With that in place and the external interface disabled (a database appliance doesn't really need to have an external interface as the GSC does), the GSC is as good a base as the LINUX appliance.

Let me know how it goes.

[markbmorgan]

OK, in trying to build, I'm hitting an issue with ocfs2, where it can't identify the kernel, probably due to the suffixing of the xen kernel. But, something I'm finding in the world is that ocfs is now built into the later kernels by default. Is there any plan to include that in appliances? That would make my life a lot easier, as it would just fall out.

[PeterNic]

Mark,

We are going to include the OCFS2 in a future beta release, which uses the 2.6.16 kernel (which is the first kernel, I think, that includes OCFS2).

For now, let me know what problems you are hitting with building OCFS2. As long as OCFS2 works with the 2.6.9 kernel AppLogic currently comes with, we should be able to get it going; from what I saw on the project's home page, 2.6.9 is supported. Note that you do need to have the OCFS2 built from source, you cannot use any of the pre-built rpms.

Regards,
-- Peter

[markbmorgan]

Any idea as to when you'll be doing that release? We're in alpha stage right now, hoping for a November full release, but needing to be able to demo in August or so.

My biggest issue is in building ocfs2 itself (the tools build fine), it gripes about not being able to determine kernel version (I think due to the -xenU suffix). I'm pulling in the source rpm for the kernel to lay out on the FS, and hopefully I'll be able to get it to compile by explicitly pointing it to the tree.

[markbmorgan]

I've got it building now. Just had to bring in the build tree and point ocfs to it.

[markbmorgan]

OK, Peter, one more twist:

We're going to need the ability to scale our a given customer's platform rapidly. So, if we find our app servers are getting overloaded, we need to be able to spin another up on demand, from within the code of one of the others. Similarly, running Oracle RAC, if we find it getting overloaded, we need to be able to instantiate another node and add it to the RAC grid. I've not dug too deeply in the docs, but will there be an API to make this possible?

Or will we just need to spin up some standby appliances and use them if needed? If so, is it possible to activate them via API? I don't want to have to redefine the customer application and move them from the current one to a new instance, as that involves service interruption that we want to avoid at all cost.

[PeterNic]

Mark, the simplest way to arrange for this is to make the app so it has the max. appliances in it. The ones you don't need to start always, you can mark as 'standby'. This way they will not take any resources except a bit of disk space, and can be spun up or down quickly, without interrupting service. See the WEBx4 and WEBx8 appliances as example (in proto catalog of AppLogic 1.2 and in system catalog in 2.0 beta).

There is no API yet but the application can use the AppLogic automation ssh interface to start and stop appliances as needed. The best way to arrange for this is to have a small appliance inside the app -- we call it the application controller appliance -- with little resources (e.g., branch off a LUX); the appliance can send 'comp start' and 'comp stop' commands to the grid controller via ssh in order to start and stop database and web servers as needed.

You can set up the appliance with its own private ssh key (on a small app volume given ONLY to this appliance); on the grid controller, simply create a user for it (e.g., myoraclecontrol@mydomain.com) with long random password and ssh key configured. We are using this mechanism for our mobile phone gateway which allows us to start/stop/restart apps from a BlackBerry (or any web-enabled cell phone), and it's working quite well.

Let me know if this will work for you or if you need more details (I can post those later tonight).

Regards,
-- Peter

[markbmorgan]

Peter, thanks for the quick response. I think that would be an acceptable method for doing things, though an API that we could call (ideally from Java) would be our preferred method.

[PeterNic]

Mark, would a web services (e.g., SOAP) API work for you? We are working on including web services API in one of the subsequent release.

[markbmorgan]

Peter -

Yes, absolutely. That would be precisely our preference!

[markbmorgan]

Peter -

One more feature that would be of huge advantage to us is a SOAP interface to the monitor appliance. Using that, we could have a controller appliance that spun up/down our additional devices as needed. Any plans to that effect?

Any idea as to the timeframe for the SOAP interface for starting/stopping appliances?

Thanks!

[PeterNic]

Mark, plans for SOAP interfaces for both are in place; no release date yet, but definitely before year's end.

[markbmorgan]

We're shooting for a November release date for the product, any chance of things being in place prior to that, by a month or so for testing/final coding?

Not to put the pressure on or anything... :)

[PeterNic]

Mark, very likely but can't promise it (i.e., it is not in active development for a planned release yet). One way to bridge this would be to create a SOAP-to-ssh converter appliance that covers the functions you need now; once we have the SOAP interfaces, you can modify the appliance to serve just as an API converter or simply remove it.

[tmart]

I'm curious about the progress of this thread because I wouldn't think that the block-level sharing capability is there in the AppLogic I/O network. Or was this a SAN implementation at Layered?