Big YES !!! (but with reservation...) If a shared storage solution is practical to implement it's the best bet.
Sounds like what you have in mind is building (a subset of) a campus cluster. Definitely the most general, robust, and elegant solution to the problem. However, it sounded to me like what was being described was a problem with limited scope and what was being requested was a solution more limited in scope and overhead. The other solutions suggested were not terribly complicated, relied only on free software and were hardware agnostic. However, we don't really know what resources are available. If the FC storage is on hand or readily acquired making this little project the first step towards a long term campus cluster solution might be an excellent investment of time and other resources. This turns the problem into an opportunity. [btw: nobody says that a campus cluster MUST be a long term thing, but if appears that it will continue to be useful -- and that seems likely -- it can be. ] If the shared storage or fiber connection just ain't gonna happen, but there's some money around, it might be worth looking at the commercial filesystems that do continuous replication via ethernet (no "shared storage"). AFIK there have been some discussions on the net about doing a free filesystem that does this but so far I haven't seen real product (and it's something I want too). The problem definition question occurs to me again. Forgive me if I sound a bit foolish. Maybe I'm just a bit slow, but it seems to me that the initial post indicated that service was at (unusually high) risk during weekends but not during the week. (Do I have this right?) This suggests the possibility of replicating the filesystem on an alternative host on Friday night and deliberately failing over to the alternate service. The "clarification" then asks for continuous replication. That's a different problem. The problem with the clarification is that it proposes a basic approach to a solution and asks for implementation details, but the problem still isn't completely clear. It would probably be a useful exercise to list: -- The problem in a concise but specific way (ie what kind of interruptions are likely during construction? Power? Network? What is the scope of the construction?, etc) -- Resources: How much time can you spend? How much money? Can you get help or are doing this alone? What's the knowledge base? (ie, have you set up clusters before? are you a scripter? etc. ) -- Constraints: When's the deadline? Are there limits on when work can be done? etc. -- Side Effects: This may include opportunity costs (putting resources into this rather than something else), effects on system availability during implementation, etc. Also residual benefits of the work you do on this. Side effects can be positive. If your solution to this temporary problem lays the ground work for a campus cluster that gets further developed and remains in service for years, the side effect will be very positive indeed. This needn't take more than a few minutes. It may help you and it will probably help the rest of us who are trying to help you. This probably all seems painfully obvious to you, but it may not be to us, and I suspect that we're each speculating a bit about what would be most workable for us, but what works for me may not work for you, etc. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
