Have you ever had something break at a bad time and end up getting
all stressed out about it. Well, this happens to me even though the
bible says we should not be anxious and should pray on all things (Philippians 4:6).
This is something from last summer. I have thought about blogging on it for some time but realistically don't have much time to blog normally. Today is my catch up.
One day I went out to our car and realized that the window was down even though I knew it wasn't left that way. Of course the first thought was that someone broke in but on a quick look it was clear that the electric window lift mechanism broke causing the window to drop into the door.
Of course, I did not want to take the car to the dealer (hate spending 2x the money for something that I can do with a little encouragement). On the same note, there is no room in the garage so rain would be a real problem. Well after a pow-wow with my wonderful wife, I decided to try to fix it myself but first got out the plastic sheeting and duct tape. I took the door panel apart and went googling for replacement parts. On a popular site, I ordered what I though was the correct part which arrived in about a week. It didn't take long to realize this was not the part for our vehicle year. It turned out that I ordered the wrong part because I didn't notice a warning on site providing the part. After fussing at myself for a good amount of time I finally was able to find the correct part and get it ordered. Another week went by. Things are getting a bit more stressed as I get concerned about the weather and the duct tape which was slowly slipping.
Finally the part arrives and my son and I spend about 4-5 hours getting the part replaced (which was not straight forward since the wiring was different). I ended up googling many sites until I found one indicating that simply ignoring several wires was ok and that polarity was apparently an issue. Remember that not everything on the internet is correct though! After redoing the wiring 2-3 times (so the window went down instead of up when pressing the down button) and repeatedly taking the door panel off about 5 times (testing, forgot to reattach parts or figured out why I had "spare parts") we finally had it all working. Yeah!
Anyways, the prayer part of the subject is that I should have been praying about even things like this from the start instead of just starting now.. where now I pray in thankfulness to Jesus for the time I had working together with my son that day. I wish that more than my hind sight was 20/20. Thankful nonetheless though.
Tuesday, May 8, 2012
Monday, May 7, 2012
DL650 VStrom Motorcycle maintenance success
I tend to like to attempt to fix things myself and after 26k miles it was time to replace the front and rear sprockets, chain, spark plugs and air filter. I ride year round down to about 15 degrees as long as it isn't icy or expecting much rain. This is mainly to save gas and reduce miles on our primary vehicles - I don't enjoy riding around with distracted drivers everywhere.
I had previously replaced the spark plugs and air filter without major incident but the rest was new. Not having a motorcycle lift but knowing that appropriate tools tend to make or break activities like this - I decided to install an electric hoist in the garage. Floor space is getting sparse and using a hoist allows me to remove both wheels for things like tire replacement or simply to ease chain maintenance. The hoist worked very well in general although there was a bit of sway to deal with.
Since I am trying to be somewhat green, I replaced the throw away air filter with a washable K&N version which is supposed to flow more air. Not sure whether the touted air flow will make a difference but not having to throw away more stuff made it a worthwhile investment.
I replaced the spark plugs with Iridium versions which I hope last longer and may provide a small power boost. The previous plugs actually still look to be in pretty good shape.
The sprocket replacements were very straight forward. I switched the front sprocket from 15 teeth to 16 and the rear from 47 to 44 teeth. This reduced the RPM down to around 4300 @ an indicated 65MPH from just about 5000 RPM. It is more relaxed and I hope to improve the fuel economy a bit.
The chain replacement was the more tedious item. I have never worked with a "continuous chain" before. This is a DID X link chain where you must press & rivet the link on (versus simply installing a clip on the side of the master link). A bolt cutter worked nicely to remove the old chain. I ended up ordering the DID KM501E tool since other methods discussed in various blogs made me a bit nervous. The results with the appropriate tools are quite nice.
On top of the normal maintenance, I decided to install the Kouba links which have been laying around the garage for about 4 years. These links reduce height of the read end by about 1 1/8 inches. I lowered the front end about .9 inches. I can now touch nearly flat footed which is nice but almost odd feeling after so long. I wish I did this a long time ago.
So far, I have not noticed much difference in power after the gearing change. It could be the better spark plugs and air filter made a small difference but I don't have any data to back that up.
My only real complaint through all this is that the plastic "rivets" which attach parts of the fairing together are very annoying on a good day.
Next maintenance will involve new brake pads which I noticed, during all this, are getting a bit thin.
I do want to credit the various contributors over at http://www.stromtrooper.com for great information which gave me enough confidence to tackle these tasks (years later than original posts in some cases).
UPDATE 2012/08/23:
The above changes have resulted in an average 65+ MPG with a high of 67.7 MPG compared to an average around 58-60MPG. That gives me a range of around 380+ miles on a tank of gas.
Have a slight (single) click when braking which I haven't tracked down yet - seems likely related to either the lowering with the Kouba links or maybe a bolt needs to be slightly tighter.
I had previously replaced the spark plugs and air filter without major incident but the rest was new. Not having a motorcycle lift but knowing that appropriate tools tend to make or break activities like this - I decided to install an electric hoist in the garage. Floor space is getting sparse and using a hoist allows me to remove both wheels for things like tire replacement or simply to ease chain maintenance. The hoist worked very well in general although there was a bit of sway to deal with.
Since I am trying to be somewhat green, I replaced the throw away air filter with a washable K&N version which is supposed to flow more air. Not sure whether the touted air flow will make a difference but not having to throw away more stuff made it a worthwhile investment.
I replaced the spark plugs with Iridium versions which I hope last longer and may provide a small power boost. The previous plugs actually still look to be in pretty good shape.
The sprocket replacements were very straight forward. I switched the front sprocket from 15 teeth to 16 and the rear from 47 to 44 teeth. This reduced the RPM down to around 4300 @ an indicated 65MPH from just about 5000 RPM. It is more relaxed and I hope to improve the fuel economy a bit.
The chain replacement was the more tedious item. I have never worked with a "continuous chain" before. This is a DID X link chain where you must press & rivet the link on (versus simply installing a clip on the side of the master link). A bolt cutter worked nicely to remove the old chain. I ended up ordering the DID KM501E tool since other methods discussed in various blogs made me a bit nervous. The results with the appropriate tools are quite nice.
On top of the normal maintenance, I decided to install the Kouba links which have been laying around the garage for about 4 years. These links reduce height of the read end by about 1 1/8 inches. I lowered the front end about .9 inches. I can now touch nearly flat footed which is nice but almost odd feeling after so long. I wish I did this a long time ago.
So far, I have not noticed much difference in power after the gearing change. It could be the better spark plugs and air filter made a small difference but I don't have any data to back that up.
My only real complaint through all this is that the plastic "rivets" which attach parts of the fairing together are very annoying on a good day.
Next maintenance will involve new brake pads which I noticed, during all this, are getting a bit thin.
I do want to credit the various contributors over at http://www.stromtrooper.com for great information which gave me enough confidence to tackle these tasks (years later than original posts in some cases).
UPDATE 2012/08/23:
The above changes have resulted in an average 65+ MPG with a high of 67.7 MPG compared to an average around 58-60MPG. That gives me a range of around 380+ miles on a tank of gas.
Have a slight (single) click when braking which I haven't tracked down yet - seems likely related to either the lowering with the Kouba links or maybe a bolt needs to be slightly tighter.
Application Server Deployment
What are drivers of an organizations deployment strategy?
The ones that come to mind are
If an organization has an investment in WebLogic or other costly technology and the deployment capabilities meet it's needs then maybe there isn't a need to do anything different than the product dictated solution. Using WebLogic or similar solution likely means there are multiple tiers and maybe load balancing of one or more tiers over multiple servers. That type of environment is substantially more complex to setup and maintain than a single tier/server solution. If the organization is staffed appropriately and has the proper training with the specific tools then doing something different seems unwise unless there is a good reason. The main downside to this solution is cost - for both the tool and either training or hiring of the appropriate staff. If the application hosted is critical then the costs multiply as well since you likely would want multiple staff trained to provide coverage during vacations or other unplanned emergencies.
Many small/mid-size organizations likely use Apache Tomcat or something similar. There are reasonably well documented install and deployment procedures available on-line or in various books. For organizations with smaller or less trained IT departments this is certainly a workable solution. Most developers are more than capable of getting a default install up and running and managing it. Applications can be scaled by load balancing multiple servers which starts to increase the complexity but is likely manageable at smaller scales. After a certain point, scaling via adding more load balanced servers and using the default deployment procedures starts to become fragile. Examples of the result of the fragility might include failed deployments, individual servers return wrong results, servers accessing wrong resources or what can be best described as flaky behavior. These problems likely stem from things such as improper change management, rushed planning, lack of reliable deployment tooling/procedures, tight maintenance windows, etc.
Are there alternatives to the above and why would an organization use them? Yes there are alternatives to the above scenarios and I will document one here. This is only an alternative and is not necessarily the best one for every organization. Each and every organization has to evaluate their resources, risks and requirements to determine what is appropriate for themselves. This alternative focuses on reducing deployment errors, speeding up the deployment process for some cases and some other benefits I will document.
The assumptions for this alternative are:
Another improvement to the overall environment includes installing the Java JDK on NFS storage and having a Linux soft-link (in a location on the NFS storage) to the current JDK in use. Any later JDK upgrade process is faster because you only need to do one install, change one soft-link and start the application up. These last 2 steps are the only steps where the application should probably be down. If you have a lot of servers to deploy to, this can be a real time saver. This also saves some space but storage is relatively cheap so the benefit is likely minimal.
Another idea is to install the Apache Tomcat software on NFS using the delivered ability to specify CATALINA_BASE and CATALINA_HOME separately. After doing this, setup a Linux soft-link (in a location on the NFS storage) to the current Tomcat. Each web server would reference the soft-link instead of the specific versioned directory that is typically referenced. The idea is to extract the read-only aspects (code) of Tomcat out to read-only NFS storage and the individual web servers have the application specific tomcat configuration files and directories (log, webapps, work). This can speed up the process of upgrading to a newer Tomcat version - especially for minor upgrades. I do recommend cleaning out any unused functionality from the Tomcat server.xml file.
If the web servers used above are virtual machines, creating more servers to increase scalability may only require cloning an existing server and making sure it is in the load balanced pool.
These same ideas can be applied to non-production applications and some aspects can be shared between applications (like the read-only NFS storage containing Tomcat and/or JDK). As the number of applications and servers increases, the benefits from these ideas increase.
And yes, you should only do this if you trust your storage system. I recommend a backup plan for handling any major infrastructure failures. Having a copy of the NFS data available for installation on the local servers is one possible method.
The ones that come to mind are
- Specific technology investments such as WebLogic (think of cluster deployments).
- Generic process based on common technology (think of Tomcat Manager)
- Custom processes, infrastructure and configuration to meet specific needs
If an organization has an investment in WebLogic or other costly technology and the deployment capabilities meet it's needs then maybe there isn't a need to do anything different than the product dictated solution. Using WebLogic or similar solution likely means there are multiple tiers and maybe load balancing of one or more tiers over multiple servers. That type of environment is substantially more complex to setup and maintain than a single tier/server solution. If the organization is staffed appropriately and has the proper training with the specific tools then doing something different seems unwise unless there is a good reason. The main downside to this solution is cost - for both the tool and either training or hiring of the appropriate staff. If the application hosted is critical then the costs multiply as well since you likely would want multiple staff trained to provide coverage during vacations or other unplanned emergencies.
Many small/mid-size organizations likely use Apache Tomcat or something similar. There are reasonably well documented install and deployment procedures available on-line or in various books. For organizations with smaller or less trained IT departments this is certainly a workable solution. Most developers are more than capable of getting a default install up and running and managing it. Applications can be scaled by load balancing multiple servers which starts to increase the complexity but is likely manageable at smaller scales. After a certain point, scaling via adding more load balanced servers and using the default deployment procedures starts to become fragile. Examples of the result of the fragility might include failed deployments, individual servers return wrong results, servers accessing wrong resources or what can be best described as flaky behavior. These problems likely stem from things such as improper change management, rushed planning, lack of reliable deployment tooling/procedures, tight maintenance windows, etc.
Are there alternatives to the above and why would an organization use them? Yes there are alternatives to the above scenarios and I will document one here. This is only an alternative and is not necessarily the best one for every organization. Each and every organization has to evaluate their resources, risks and requirements to determine what is appropriate for themselves. This alternative focuses on reducing deployment errors, speeding up the deployment process for some cases and some other benefits I will document.
The assumptions for this alternative are:
- mid-size organization
- understaffed IT with wide duties
- critical applications with at least a moderate rate of change
- basic web application (multiple load balanced web servers and 1 DB server)
- NAS NFS storage
- Apache Tomcat
- Linux based Web servers
Another improvement to the overall environment includes installing the Java JDK on NFS storage and having a Linux soft-link (in a location on the NFS storage) to the current JDK in use. Any later JDK upgrade process is faster because you only need to do one install, change one soft-link and start the application up. These last 2 steps are the only steps where the application should probably be down. If you have a lot of servers to deploy to, this can be a real time saver. This also saves some space but storage is relatively cheap so the benefit is likely minimal.
Another idea is to install the Apache Tomcat software on NFS using the delivered ability to specify CATALINA_BASE and CATALINA_HOME separately. After doing this, setup a Linux soft-link (in a location on the NFS storage) to the current Tomcat. Each web server would reference the soft-link instead of the specific versioned directory that is typically referenced. The idea is to extract the read-only aspects (code) of Tomcat out to read-only NFS storage and the individual web servers have the application specific tomcat configuration files and directories (log, webapps, work). This can speed up the process of upgrading to a newer Tomcat version - especially for minor upgrades. I do recommend cleaning out any unused functionality from the Tomcat server.xml file.
If the web servers used above are virtual machines, creating more servers to increase scalability may only require cloning an existing server and making sure it is in the load balanced pool.
These same ideas can be applied to non-production applications and some aspects can be shared between applications (like the read-only NFS storage containing Tomcat and/or JDK). As the number of applications and servers increases, the benefits from these ideas increase.
And yes, you should only do this if you trust your storage system. I recommend a backup plan for handling any major infrastructure failures. Having a copy of the NFS data available for installation on the local servers is one possible method.
Subscribe to:
Posts (Atom)