This is a deck that we use to educate customers on sizing/configuring a grid optimally. This may have a lot of what some people would consider obvious information but it's useful to write it all down regardless.
« December 2008 | Main | March 2009 »
This is a deck that we use to educate customers on sizing/configuring a grid optimally. This may have a lot of what some people would consider obvious information but it's useful to write it all down regardless.
Posted at 06:14 PM in WebSphere eXtreme Scale Videos | Permalink | Comments (0)
|
We just updated the trial version of WebSphere eXtreme Scale so that it's easier to get a grid running after downloading it. I think the new gettingstarted folder will allow people to have a working grid within ten minutes of downloading. The update allows a single grid of JVMs to be started and includes a client to perform insert/get/update/remove operations on that grid. Please post any feedback here or on the forum.
It should now be as simple as download the trial, set JAVA_HOME to your current JVM and then run the provided scripts in gettingstarted.
Posted at 04:23 PM in WebSphere eXtreme Scale | Permalink | Comments (1)
|
We have a pretty huge test bucket for WebSphere eXtreme Scale, it been growing now for a couple of years and it current takes a couple of days just for the auto FVT bucket to run and then we do the testing that we haven't automated yet. Quality is a big deal in the XTP/DataGrid business so it's always on my mind, more so than performance or function. Everyone wants perfect software with no bugs. We can strive towards that goal with larger and larger test case buckets written by developers and do code reviews etc but sometimes bugs still get out. The bugs are harder to come by these days and I'm finding the study of epidemics is an interesting approach to how testing happens.
Posted at 10:51 AM in Testing | Permalink | Comments (0)
|
I just read an excellent summary of the principles of doing this at this site. The points especially relevant to achieving this for WebSphere eXtreme Scale are the following.
Here, this is how common data is handled. The comments are a great example. Duplicate the comments in to each partition and the partition is then keyed by the main key. This allows logic for the main key to be handled within a single partition without having to talk with other partitions which are almost 100% going to involve network IOs.
Here, group related data needed for the partitioned entity underneath this object. WXS provides a tree schema for each partitionable entity. Placing all needed data linked to this tree keeps it all local and eliminates network hops to fetch it. This is really an amplification of the "Duplicate data" rule.
Model the data in a form compatible with the business logic to be executed on it. This makes writing the logic fast and keeps the data close the to logic. This avoids joins.
Add extra attributes with commonly calculated values, don't use queries to calculate them, update the total attribute when something changes and just query it. Assuming the queries are more frequent than the updates then this saves a lot of time.
This again is to avoid the small entities created when using a fully normalized model. Normalizing means joins and joins are expensive so try to avoid them if at all possible.
The framework like WXS can't manage these denormalized models automatically for you. You'll need a model which knows how to do this and does it automatically when changes are written to the model. This model can run inside the grid collocated with the data so it's going to run fast.
This basically says that rather than having a model which has a Company has a collection of employees, have a model with companies and employees with a list of companys. The list in the latter case is MUCH smaller than the other way.
This is kind of dangerously obvious but if you have a tera byte of data in a grid, don't ask for a sorted list of all records and send it back to my client app. The app will die. Bound it to the top 10 or 20 items.
This kind of goes without saying. If you use a single record in the grid all the time then it's going to bottleneck there so try to avoid or rather don't do this.
Summary
The linked article is pretty cool and summarizes much of what we already knew about the best practises on designing for DataGrids. So, here it is, enjoy.
Posted at 02:37 PM in WebSphere eXtreme Scale | Permalink | Comments (0)
|
Hosting applications on platforms such as Amazon EC2, its competitors or on private clouds almost requires elastic scaling. Elastic scaling means that adding or subtracting virtual machines to/from the application farm is handled by the application in a transparent way.
The easiest scenario here is a completely stateless application. Here, adding or removing a machine and then incorporating it to the router will achieve that effect but such applications are rare as a database is usually involved.
Databases are typically not elastic. An Oracle, DB2 or mysql database typically runs on a single machine and besides moving the machine to a bigger machine, that's as far as that goes. The good news here is modern machines are very fast so that can still go a long way. Techniques like database sharding where the data is split between several databases with a directory database storing the record locations or some consistent hashing approach is next usually in terms of solving the database but this is extra work also and it doesn't handle failover etc.
A combination of WebSphere eXtreme Scale and a database is an interesting scenario which easily adds elastic scaling to the persistence tier as we'll now see. WebSphere eXtreme Scale provides out of the box elastic scaling for both HashMap style or queue based XTP. Adding and removing 'boxes' will result in automatic and transparent incorporation of the change in to the grid. WebSphere eXtreme Scale can use OpenJPA or Hibernate to interface between the grid and the database to seamlessly incorporate data preload, lazy read, sync write or write behind write behaviors of data. Failover and high availability are inherent in a product like WebSphere eXtreme Scale. WebSphere eXtreme Scales zone support can also ensure replicas are running in different Amazon EC2 zones providing out of the box higher availability levels without the cost of a fully mirrored system.
We see this pattern of WXS as system of record with write behind to a conventional database as a very common pattern. The application tier makes service requests on WXS for the data and WXS can be scaled elastically depending on the load/capacity requirements. More machines means more memory, CPU and network bandwidth. This elastic scaling architecture allows hosted applications on public or private clouds to scale seamlessly by leveraging WXS to provide elastic persistence services with the database running behind it on a VM that can be restarted quickly on a failure.
A typical Amazon EC2 setup might be an EBS (Elastic block store) volume where the database logs and data are stored. An AMI for the database and an elastic IP. An AMI is a virtual machine definition. This includes the operating system, installed sofware, scripts etc. An instance of the database AMI is started which creates the actual virtual machine using that AMI, the user then attaches the EBS volume and elastic IP to that virtual machine instance. Now we have a running database. If the virtual machine fails then we restart the AMI on a new instance, connect the EBS and elastic IP to the new virtual machine instance and keep going. Downtime should be under 5 minutes if its automated. Backups are a piece of cake with EBS as a customer can create a snapshot of the EBS volume at any time and then start another database instance using that snapshot to run offline reports or they could simply push the snapshot to S3 for archiving. Whats an elastic IP? Amazon EC2 virtual machines receive random IP address when they start. We need our database in a well known place so we can connect to it. An elastic IP is a public static IP address that you can ask Amazon for and then associated with a virtual machine. You can move it from a virtual machine to another if needed (failover for example).
Next is the persistence tier. This runs a collection of identical AMIs with the WXS stack inside. Whats in the stack? Linux, JVM, WXS, Hibernate/OpenJPA, database jdbc driver, any application POJOs and xml files for the grid. These virtual machines don't need elastic IP addresses as WXS virtualizes the collection as a single resource for the application. We'd recommend running at least three of these to lower the odds of a double failure. This stack has the Maps for all the data and each Map is configured to use our JPALoader and say OpenJPA to connect the map with the database. The database is configured to use the elastic IP as the database host name. The WXS AMIs all connect to a pair of WXS catalog servers running on two virtual machines with two elastic IPs. The customer may try to load all the data in to WXS, just load the hot set in to memory initially or do lazy loading where data is only loaded when it's first referenced. If the dataset is larger than will fit in memory then our heap level triggered evictor can help there. It will evict data on an LRU basis when the JVM heap reaches 70% full. This keeps the system from running out of memory even when failures scale down the grid capacity. Fixed map limits or TTLs will NOT protect you in an elastic system. Our heap level eviction will.
Next is the application tier. This can be running in the same virtual machines as the WXS stack. This would work if the WXS and application tiers scaled linearly together. The application tier might just be a tomcat JVM or WebSphere CE. If its a web application then WXS can provide HTTP session failover as well as the persistence service.
The database tier doesn't need to be elastic as the persistence tier services the application tier directly and uses the database only for long term storage. The database is also useful for handling reports etc as standard reporting tools will work with a database but none will work with a DataGrid type product. Even ones with SQL APIs may have substantial trouble running complex queries on a partitioned datagrid so a database is probably still best bet for reports. The database will be slightly behind the data in the grid but only a few seconds.
Lastly, a routing tier will accept incoming requests and spray them on to the application tier. This could be as simple as round robin DNS but given the need for elastic IPs then I'd expect some kind of proxy server to be running there, probably two for redundancy. The routers would have elastic IPs and DNS would be configured to use those.
WXS needs a couple of JVMs running the catalog service (this manages WXS) and these can be run in a separate couple of virtual machines or inside say the first two WXS virtual machines. They need an elastic IP address. The application is configured to connect to the grid using these IP addresses. The catalog service manages laying out the grid and clients boostrap to it to obtain a connection to the grid.
This example architecture is fully elastic out of the box. Adding virtual machines will elastically scale the application and persistence tier. The database tier doesn't need elastic scaling because of the WXS based persistence tier. It's implicitly highly available given the nature of WXS providing the persistence service and a manual mechanism for restarting the database would work as even if the database was down, WXS could service all reads and updates. Clearly, reads are only serviceable if they were already cached in the WXS tier. When the database restarts then the pending dirty writes will be flushed to the database.
I hope this shows the value of elastic scaling in middleware products like WebSphere eXtreme Scale. Virtualized environment provide a very simple production environment of homogenous machines and lowers the complexity of trying to do this. It can be done on virtual environments in the cloud or private environments in a company. Without elastic scaling in the persistence tiers then scaling out the elastic application tier will only work so far. The database will be a big issue unless you've built your own sharding layer and you still need to handle failover or replication to make it all fault tolerant. The WXS based persistence tier is significantly less difficult to deploy because it has fully elastic scaling. This means you can focus on the business logic and leave this aspect to middleware making your project more successfull, cheaper to developer and gives you a fast time to market.
Posted at 05:06 PM in WebSphere eXtreme Scale | Permalink | Comments (2)
|
The Java community is currently focused around JPA as the persistence API but I think it's missing the big picture. JPA is a combination of several facets which themselves need to be separated into separate specifications so that we can get a better programming model.
Posted at 07:27 PM in Persistence | Permalink | Comments (20)
|