| تبليغات | X |
|
XGRID تکنولوژی
|
||
|
پیاده سازی سیستم های توزیع شده |
منبع : http://www.gridbus.org/vlab
Enable existing applications for grid
If you are familiar with the six strategies for grid application enablement, you might want to apply one of the frst three of them to an existing application. This article shows you what to consider to grid-enable platform-specific distributed applications (monolithic and modular) and Web-enabled applications (servlet-centric and database-centric).
Before using the techniques described in this article, make sure you are familiar with the six strategies for grid application enablement described in the following "Six strategies for grid application enablement" series of articles:
In this article, we introduce the basic architectural pattern that fits most cases when you enable existing code. Next, we discuss a few strategies to enable existing code based on the most common architectures we have encountered over the years. We introduce two basic scenarios for platform-specific distributed applications, and we will study the most common architectural variations of each scenario and the most common way to make these architectures fit into the enablement pattern. We conclude with two scenarios for Web-enabled applications (servlet-centric and database-centric).
Most enablement efforts for existing code using batch-oriented grid infrastructure software are similar. There's a pattern you can follow. You can use this pattern to achieve the first three strategies of grid adoption.
The base case for these three strategies for grid adoption is a program that takes command-line parameters and uses files or databases as specified in the command-line parameters. If the program is licensed, the grid infrastructure will require license management capabilities.
In general, the first three strategies to enable an existing application to run on a grid all require the user to send requests to a client application, which acts as a requester to the grid infrastructure. The client to the client application can be the actual user or a portal. The grid infrastructure takes care of deploying the actual application, which becomes a provider to the grid infrastructure. See Figure 1.
Figure 1. Integration pattern for enabling existing code
The key point is that the client program (job submission driver) should talk to the grid infrastructure as if it is talking directly to the application. The simplest way to do this is by having the client program issue command-line type instructions to the virtualized application.
Implementing this scenario is easy when the application is a stand-alone program with minimal deployment requirements. But when you're dealing with integrated applications, the whole thing might require a little creativity.
Enabling existing code using batch-oriented grid infrastructure software involves a finite number of known scenarios because of the state of the software industry today. Two scenarios exist, both involving essentially the same type of application:
Enabling platform-specific distributed applications
As previously mentioned, this scenario applies to client/server, transactional, and batch-oriented applications. Two architectural tendencies prevail in these three types of applications: monolithic and modular.
The case of monolithic applications
In general, deploying platform-specific monolithic applications on batch-oriented grid infrastructure software is as simple as installing the application on all grid nodes and writing some "glue code" that will integrate user requests, parameter passing, and program calls from the grid infrastructure. See Figure 2.
Figure 2. Deploying monolithic applications using the standard enablement pattern
This "glue code" we're talking about is what makes this an integration job. In most cases, you can integrate a monolithic application and a batch-oriented grid infrastructure product through scripting. You can use Perl, Python, or ordinary shell scripts to integrate user requests, parameter passing, and application calls within the context of the grid infrastructure software.
The caveat has to do with what a monolithic application does and how it does it. Monolithic applications tend to try to be all things to all people. That's one reason they're monolithic (modules are not trustworthy to some people). Sometimes, monolithic applications have, among other things, embedded grid functionality. Embedded items and the way in which such functionality was implemented will determine whether the application can run on a grid.
For instance, a monolithic application that does not have any built-in grid infrastructure functionality will be easier to enable than others. An example would be a similar application that, on top of doing what it is supposed to do, also takes care of tasks such as scheduling which instance processes what request, or which database tables need to be locked on behalf of a given user, or when transaction affinity needs to be enforced. However, we still need to look into how the built-in grid functionality was implemented.
If the built-in grid functionality can be turned off from within the application, then this monolithic piece of code will be able to run on top of batch-oriented grid infrastructure software with no problem. If, on the other hand, the grid functionality is built deep into the application and it cannot be turned off, then we have a problem.
In general, the extent of the work needed to turn off built-in grid infrastructure functionality is very high. When programmers were learning to reuse code, they also learned to abstract functionality both ways: up and down. Embedding grid infrastructure features in business logic frameworks is an example of abstracting functionality down.
We can't blame programmers for doing this. At the time when most platform-specific distributed applications were written, very few people were thinking about grid computing. At the time, nobody even considered the possibility of finding ready-made containers for their applications, much less complete grid infrastructures where they could just deploy their code and move on with their lives.
The case of modular applications
In general, enabling modular platform-specific distributed applications will be easier than enabling monolithic applications. The reason I say this is that modular applications give you choices on how to deploy them. There are caveats just as in the previous case, but with modular applications, easier ways to get around them.
One of the main advantages modular applications have is the possibility of turning off modules when necessary. This way, any environment-related functionality can be rendered to the grid infrastructure.
As in the case of monolithic applications, the existence of built-in grid features and whether they can be turned off or stripped out will also determine the degree of difficulty for the grid enablement effort.
The difference is that most modular applications, when they have any built-in grid features, will most likely concentrate that functionality in a single module, or a group of specialized modules. This should make it easier (in theory) to turn those modules off or to just eliminate them altogether.
This caveat is inter-module communication. The degree of difficulty in turning off, or stripping out, application modules depends on how the designers implemented inter-module communication. In general, the simpler the transport, the lower the degree of difficulty.
For instance, it is common for applications of this kind to have a dedicated module to handle all database calls. In some cases, the module not only acts as a universal database client by supporting ODBC or JDBC drivers for several vendors but also does something we can call "table access scheduling," which is sort of an intra-application table-locking mechanism that allows the application to handle table locking independent of the database.
Having a universal database client is a good idea. However, if the application is to be grid-enabled, it is better to leave table locking to the data grid infrastructure (let's assume that's what we're doing with the application). So, all we need to do is substitute the module for a regular database client, deploy the RDBMS into the data grid, and we've got ourselves a grid-enabled application.
Most database clients and listeners rely on TCP/IP sockets to get their orders from a program. The DB2® client listens by default on port 50000, for example. But what if the application designers decided that the tried-and-true way of TCP/IP sockets was not fancy enough for their application? What if they decided to go with a proprietary mechanism for inter-module? Then the problem is not so straightforward anymore.
There is another aspect to inter-module communication that can turn out to be a show-stopper. If the application is to be deployed on a computational grid, there can be several instances of several modules running concurrently on the grid. If the grid infrastructure software cannot relay the transport mechanism, or if the transport mechanism itself cannot function on a grid environment, the application simply will not work as expected.
Then, the degree of difficulty for the grid enablement project will be directly proportional to the effort of replacing the inter-module communication mechanism.
Deployment strategies: best-case scenario
An ideal modular application should handle inter-module communication with a dispatcher -- or broker -- module. This plan would allow modules to be deployed anywhere on the grid because inter-module communication will always happen through the broker. See Figure 3.
Figure 3. Ideal deployment for modular applications
The best-case scenario has two very desirable behaviors. First, application modules should be atomic to allow independent deployment from one another. The dispatcher-broker module should take care of all inter-module communication and data exchange.
As for shared libraries, the grid infrastructure should be able to handle them if they're installed as part of a system-wide installation. If not, they can be included as part of the provisioning policy for all modules so that all nodes have a local copy.
Second, application modules should be granular enough to allow for multiple instances of the same module to run concurrently (at least) on the same machine. A module should take care of its own results aggregation. Application-level results aggregation can be handled by the dispatcher-broker module or by through the database.
Deployment strategies: most-common scenario
Unfortunately, most modular applications are not that well behaved. In some cases, module encapsulation is not atomic enough to allow for true independent deployment. In other cases, the dispatcher-broker module doesn't take care of all inter-module communication and data exchange. Instead, some modules call on each other directly, which forces them to reside on the same machine.
Results aggregation also represents a problem, especially when the dispatcher-broker doesn't fully own the task of managing inter-module communication. Some modules might feed their results into other modules instead of just passing them back to the broker. Whatever the situation, the most common scenario is to deploy the entire application on all grid nodes as shown in Figure 4.
Figure 4. Most common scenario for deploying modular applications
To an extent, the most common scenario means that a modular application can be deployed as a monolithic application if worse comes to worst. It should work but the advantage of being modular will be lost because it won't be exploited by the grid infrastructure as in the ideal case.
In the same vein, think of a monolithic application as a single-module modular application and treat it as such when devising a strategy for managing results aggregation in the case of multiple concurrent instances.
These two cases, monolithic and modular applications, represent the simplest scenario when it comes to grid enabling platform-specific distributed applications. The situation changes dramatically when we deal with Web-enabled applications, as you'll see in the next section.
Enabling Web-enabled applications
A Web-enabled application is not a true J2EE application. We call "Web-enabled" those applications that were written originally as platform-specific distributed applications but run as Web applications, thanks to a Web front end.
The most common architectures are known as servlet-centric and database-centric, and each poses its own challenges to grid enablement.
Servlet-centric applications, in general, follow the architectural pattern illustrated in Figure 5.
Figure 5. Most common Servlet-centric architectural pattern
The platform-specific application in Figure 5 is, in some cases, patched up to support things such as XML and other technologies. It is enabled to talk to a Java™ Virtual Machine via JNI or a proprietary connector framework. As for database support, it is common to use ODBC-to-JDBC bridges or to just stay with ODBC.
When "ported" to run on J2EE application servers, servlet-centric applications interact with clients via a gateway servlet, which relays requests to the connector and thus to the actual application. A typical porting to an application server, such as IBM® WebSphere® Application Server, looks like the one illustrated in Figure 6.
Figure 6. Typical servlet-centric Web enablement strategy
Enabling an application that follows this execution pattern run on a grid would require at least the following steps:
The resulting scenario is illustrated in Figure 7.
Figure 7. Typical servlet-centric grid deployment
It might be necessary to change some of the original assumptions when implementing this scenario. For instance, a deployment like the one shown in Figure 7 would probably be easier to manage if the gateway Servlet ran on WebSphere Application Server Express, which doesn't include an EJB Container, as opposed to WebSphere Application Server Advanced Edition, or Apache Tomcat. A change of this nature would actually benefit your customers because it could lower the total cost of the application.
Keep in mind this is just one way of doing it. There may be better ways to architect the deployment pattern depending on the characteristics of the application. The best solution should provide the best returns in terms of feasibility, effort, usability, and administration.
The issues affecting monolithic and modular applications can also affect servlet-centric grid enablements. In addition, issues related to application performance can also arise.
Servlet-centric applications, in most cases, will experience performance problems at the Web container level. The use of a gateway servlet can create a sometimes nasty bottleneck that stems from, among other reasons:
These issues have nothing to do with the grid infrastructure. They can cause problems even if the application is not running on a grid. You need to be aware that you will have to tune the application server under the new conditions once the application is deployed on a grid. Other issues can stem from the interaction of the application server and the grid infrastructure. For instance:
Sometimes these problems, when they all surface at the same time, make the whole grid enablement exercise too complicated and too costly to be worth the effort. Sometimes it's better to consider the possibility of deploying the platform-specific piece of the application as a regular monolithic or modular application (whichever applies), or to rewrite the platform-specific piece as a J2EE-compliant set of components and look for an SOA-based grid infrastructure.
Database-centric applications became the de-facto standard back in the day of the client/server paradigm. Tools such as PowerBuilder, Oracle 2000, PacBase, Progress, and other products were widely used to create monolithic, footprint-heavy, and large applications that required proprietary languages and specialized skills to understand them.
Some products of this type managed to adapt to the new distributed paradigm and gave us these Web-enablement hybrids we know now as database-centric applications. Some vendors claim having re-engineered their products to be truly distributed and Web-native, but for some products, under the wraps, the old client/server, monolithic architecture remains untouched.
This situation is understandable given that most vendors even invented their own languages to describe highly complex frameworks aimed to facilitate what was called in those days "Rapid Application Prototyping and Development."
Regardless of the technical value of these products, vendors need to preserve this intellectual capital for one simple reason: A lot of money was invested in their development. Therefore, database-centric applications are going to be around for a long time.
Common implementations of database-centric applications revolve around proprietary frameworks. In most cases, these frameworks have been "patched" to support Java technology, XML, and JMS, on other now-popular industry standards. Figure 8 illustrates the most common flavor of this architecture.
Figure 8. Most common database-centric architectural pattern
In most cases, the application and the database are bound together in a single package, and there's no difference between business logic and database operational logic. Because of this, added support modules do not interact natively with the original application.
Porting scenarios for database-centric applications are usually done through the Web container, as shown in Figure 9.
Figure 9. Typical database-centric Web enablement scenario
The strategy is similar to the one used for servlet-centric applications. It involves writing a gateway servlet that accesses the proprietary framework through the add-on Java support modules as dependent classes, or through XML files.
Treat it as a monolithic application
The easiest way to grid-enable a database-centric application is to treat it as a monolithic application. In this case, you would need to implement the deployment pattern shown in Figure 9.
But there's an interesting characteristic about database-centric applications that might provide a more efficient way to deploy certain applications on a grid.
Database-centric applications use the database not just to store data but also to keep configuration information, workflow data, and even presentation metadata. This dependency on the database is sometimes so tight that it is impossible to separate the database from the runtime environment. In some cases, the application actually runs on top of the database engine.
In cases where the database run time is the application run time, what can be virtualized is not the business logic but the data. You need to use a data grid instead of a computational grid as in the previous scenarios.
By virtualizing a database-centric application on a data grid, you would be indirectly virtualizing the application run time and, thus, the application itself. All the data the application needs to run will be made available locally on all nodes on the grid and, whenever the application changes, the modifications will be propagated automatically.
What happens is that you get location independence for the requests going to the database while the data is propagated all across the grid. To the requesting program, the data seems to be local all the time when, in reality, it can be located anywhere on the grid. So, what runs as a single-instance batch job is the request broker (the Java interface and a driver for the thick client) while the data is virtualized by the grid infrastructure.
Depending on how the business logic is written, you might be able to virtualize the data and the business logic as shown in Figure 10.
Figure 10. Data virtualization scenario for database-centric applications
Note that you can virtualize data and business logic on a data grid only if the business logic runs in processes triggered by the database engine, which is the case of most proprietary frameworks.
If, on the other hand, the business logic can be triggered by an outside process, such as the job submission driver, you might be able to actually separate data from business logic in what would be a combination of a computational grid for the business logic and a data grid for the database. This approach, however, might not be a feasible solution in some cases because it could introduce too much complexity into the deployment model.
Database-centric applications usually have a characteristic of being heavy on CPU and memory usage. This demand becomes especially visible when the database run time also runs applications.
In some cases, a grid deployment exercise might not work as expected due to the overhead created by the data grid itself, plus the overhead caused by a resource-hungry database runtime environment. In other cases, when it is possible to separate the data and the application, the situation resembles the case of monolithic applications and the same issues will apply.
The information in this article should give you enough ammunition to start brainstorming about the best way to grid-enable your product. If you want to grid-enable platform-specific distributed applications (both monolithic and modular) and Web-enabled applications (both servlet-centric and database-centric), this article shows you what to think about.
GPU, a Global Processing Unit
SourceForge.net: Project Summary: GPU, a Global Processing Unit (gpu project)
A summary of key project details for the gpu project on SourceForge.net.
An extensible framework for distributed computing on P2P grids. We support peaceful free and open research and build an internet supercomputer. We render movies, solve Eternity puzzles, crawl the internet and improve a ~30 GHz cluster of Gnutella clients
| Site URL: | http://sourceforge.net/projects/gpu/ |
توان اضافی رایانه خود را برای پیشرفت علم اهدا کنید
با نصب نرم افزار موجود در سایت برنامه رایانه شما زمانی که از توان CPU خود بطور کامل استفاده نمی کند (و در واقع توان استفاده نشده خود را به هدر می دهد) می تواند برای انجام محاسبات پیچیده مثل شبیه سازی داروها برای درمان بیماریهایی نظیر ایدز سرطان و ... مورد استفاده قرار گیرد (Distributed Computing). به همراه میلیونها نفر از سراسر جهان در این طرح (World Community Grid) بشردوستانه شرکت کنید. نتایج همکاری خود را در بخش نتایج (STATISTICS) می توانید مشاهده کنید. این طرح ابتدا توسط IBM اغاز شده بود و در حال حاضر توسط بسیاری از دانشگاههای امریکا پشتیبانی می شود.
منبع : www.worldcommunitygrid.org
گوگل بعدی در راه است
در قالب يك پروژه جديد شركتي آمريكايي با نام looksmart قصد دارد تا با استفاده از فناوري grid Computing يك موتور جست وجوي اينترنتي قدرتمند را توسعه دهد. اين فناوري در حقيقت از توان پردازشي بلااستفاده رايانه هاي در حال كار با اينترنت و پهناي باند اينترنتي رايانه هاي شخصي استفاده نموده و با شناسايي سايت هاي گوناگون و طبقه بندي آنها، فهرستي طويل از آنها را به عنوان بانك اطلاعاتي مورد نياز براي يك موتور جست وجو بوجود خواهد آورد.
بدين منظور يك سايت اينترنتي با نام grub و در آ درس http://www.grub.org راه اندازي شده است كه كساني را كه داوطلبند تا توان پردازش اضافي رايانه خود را كه هنگام كاركردن آنها با رايانه بلااستفاده است به اين امر اختصاص دهند به خود جلب نموده و قدرت بلااستفاده دستگاه هاي آنها را قرض مي گيرد.
داوطلبان شركت در اين پروژه به سايت grub مراجعه نموده و نرم افزار مخصوصي را دان لود مي كنند.اين نرم افزار با استفاده از قابليت هاي رايانه هاي كاربران متصل به اينترنت به جست وجوي اينترنت پرداخته و اطلاعات مربوط به سايت هاي اينترنتي را جمع آوري مي كند. اين اطلاعات در مركز بانك اطلاعات grub ذخيره مي شوند.
grub كه به تازگي آغاز به كار نموده است ،توانسته تا ظرف مدت ۲۴ ساعت حدود ۳۶ ميليون سايت اينترنتي را شناسايي و فهرست نمايد، مسئولان شركت looksmart اميد دارند تا با استفاده از اين فناوري به تدريج چنان حجم اطلاعات فهرست شده خود را بالا ببرند كه بتوان به كمك آن موتور جست وجويي قدرتمند را راه اندازي نمود و بروز نگاه داشت. آنها اميدوارند تا روزي grub با قدرتمندترين موتور جستجوي اينترنت يعني گوگل برابري نمايد و حتي از آن پيشي گيرد.
اين طرح موافقان و مخالفان بي شماري دارد. گروهي براين باورند كه قرض دادن توان اضافي رايانه ضربه اي به ايشان وارد نمي نمايد اما برخي براين عقيده اند كه نبايد اجازه داد تا looksmart بدون پرداخت هيچ گونه هزينه اي از امكانات آنها استفاده كند.
انسان ها تنها از ۱۰ درصد قدرت مغز خود و شايد به زحمت از ۹۰ درصد قدرت رايانه هايشان استفاده مي كنند. چنانچه امكان grid computing در مورد مغز ها نيز وجود داشت شايد وضع بشر بسيار بهتر از اين بود.
منبع : http://www.grub.org
گوگل و آی بی ام موانع علوم رایانه ای را برطرف می کنند
آی بی ام و گوگل در حال ارائه متدهای جدیدی برای توسعه نرم افزارهایی هستند که به دانشجویان و محققان امکان مواجهه با چالش های در مقیاس اینترنت را فراهم می کند.
به گزارش خبرگزاری مهر، آی بی ام و گوگل سخت افزارها، نرم افزارها و سرویس هایی را برای گسترش افق جدید تحقیق ارائه می کنند که بتوانند موانع موجود بر سر راه جامعه دانشگاهی در توسعه بررسی های مدل های نوظهور محاسباتی و ساخت رایانه های جدید را برطرف کنند.
هدف از این اقدام افزایش آگاهی محاسبه موازی زیاد از طرف دانشجویان علوم رایانه به منظور مواجهه با مشکلات انفورماتیکی در مقیاس زیاد است.
در حقیقت این دو شرکت قصد دارند روش هایی را ارائه کنند که به دانشجویان و دانشمندان در توسعه آسانتر شبکه و ساخت رایانه های پرقدرت نسل آینده کمک کند.
دانشگاه واشنگتن، دانشگاه کرنگی ملون، موسسه تکنولوژی ماساچوست (ام آی تی)، دانشگاه استانفورد، دانشگاه برکلی و دانشگاه کلمبیا، اولین دانشگاه هایی هستند که در هدایت این پروژه شرکت کرده اند.
اریک اشمیت مدیر اجرایی گوگل در این خصوص اظهار داشت: گوگل از شراکت با آی بی ام برای ارائه راه حل هایی به دانشجویان و محققان در چالش های موجود در توسعه علوم رایانه ای و فراینده های محاسباتی، بسیار خرسند است. واضح است که دانشجویان و محققان از ابزارهای دقیقی برای توسعه سیستم های محاسباتی و رایانه ای موجود برخوردار هستند و بدیهی است که در توسعه فناوری های نوآورانه با مشکلاتی نوظهوری مواجه می شوند.
براساس گزارش کامپوتر وورد، تغییرات بنیادی در معماری رایانه ها و افزایش توانایی شبکه به توسعه دهندگان نرم افزار نیاز دارد که بتوانند شیوه های جدیدی را برای حل مشکلات علوم رایانه ای پیدا کنند.
برای نرم افزارهای روی شبکه مثل موتورهای جستجو، شبکه های اجتماعی و تجارت الکترونیک اغلب به دسته بندی محاسبات رایانه ای در کسری از اعشار نیاز است که بطور همزمان روی سرورهای مختلف گذاشته شوند.
تکنیک های برنامه ریزی موازی برای بررسی های علمی پیچیده مثل تجزیه ژنتیکی و مدل های آب و هوایی نیز مورد استفاده قرار می گیرند.
در این خصوص ساموئل جی. پالمیزانو، مدیر اجرایی آی بی ام اظهارداشت: این پروژه همراه با قدرت سنتی آی بی ام در عرصه تحقیقات علمی و تجاری و قابلیت های گوگل در محیط رایانه ای وب و گروه های مقیاس پذیر اجرا می شود. هدف ما آماده سازی برنامه نویسان فردا برای ساخت نرم افزارهایی در حمایت از رشد شبکه جهانی و میلیاردها داد و ستد بازرگانی روزانه است.
این دو شرکت بزرگ انفورماتیکی نگاه خود را به آینده ابر محاسبه (cloud computing) معطوف کرده اند. ابر محاسبه موجب قدرت بررسی های محاسباتی در سرویس های نسل جدید وب 2.0 می شود و هدف این پروژه بررسی و گسترش این قدرت است. با استفاده از پردازشگرهای ابر که بصورت شبیه سازی به رایانه ها امکان محاسبه تعداد زیادی عملیات را می دهد، دانشگاه ها می توانند اطلاعات خود را با قدرت بالا و سرعت زیاد محاسبه کنند.
گوگل و آی بی ام، قدرت گروهی از حدود صد سیستم متشکل از فناوری های گوگل و BladeCenterو سرور سیستم ایکس آی بی ام را تا رسیدن به هزار و 600 پردازشگر افزایش می دهند. دانشجویان می توانند از راه اینترنت وارد این گروه ها شوند.
منبع خبر : خبرگزاري مهر
سیستم های محاسباتیGrid متن باز اروپایی جدید می شوند
دو گروه اصلی شرکتها و انستیتو آکادمیکی تحقیقاتی، هر دو در حال آماده کردن نرم افزار Gridمتن باز خود می باشند.
محاسبات Grid قصد استفاده از منابع محاسباتی توزیع شده جغرافیایی خود را با ترکیب آنها به صورت یک ابر کامپیوتر مجازی دارد.چنین سیستم هایی می توانند مشکلات محاسباتی و داده ای شدید درعلوم، مهندسی و مخابرات را حل کنند.
Unicore در 28 آگوست 2007 در فرانسه به نمایش version 6 نرم افزار Middleware Grid پرداخت.
XtreemOS ، نسخه اول از نرم افزار Grid خود را که برپایه GNU/Linux بود، در یک جولای، در یک کارگاه در ایتالیا به نمایش گذاشت.گفتنی است XtreemOS، یک کنسرسیوم است که شامل شرکتها و محققان در فرانسه، انگلستان، ایتالیا، آلمان، اسپانیا، هلند و اسلوونی می باشد.
این گروه امید به ساختن یک سیستم دارد که تمامی توانایی های مربوط به نرم افزارMiddleware Grid را دارا بوده و علاوه بر آن به طور کامل در سیستم عامل دوباره جمع آوری شود.
کنسرسیوم Unicore، به انتشار نسخه آخر برای استفاده در معماری های مبتنی بر سرویس می پردازد.Unicore، توسط Intel در Brühl و Fujitsu در لندن و دانشگاه Warsaw و CINECA و انستیتو تحقیقاتی آلمان در Jülich توسعه داده شده است.
نمایندگان هردو گروه در کنفرانس اروپایی Parallel Computing که در سال 2007 در Rennesبرگزار می شود، شرکت می کنند.
منبع خبر:
http://ec.europa.eu/idabc/en/document/7184/469
Further information
صرفه جويي درپهناي باندبا سرورهاي كلاسترشده
HP ادعا ميكند كه Lustre ميتواند پهناي باند را تا 100 برابر سيستم
كلاسترينگ كنوني افزايش دهد.
|
|
|
 |
همهی شما دست کم یکبار تجربهی جست و جو در سایت Google™ را داشتهاید و بیگمان متوجه زمانی که "با افتخار" در بالای نتایج جستوجو و در کنار تعداد صفحات پیدا شده نوشته میشود گشتهاید. پیدا کردن صدها هزار صفحه در کسری از ثانیه واقعاً افتخار هم دارد. اما چه گونه چنین کاری ممکن است؟
در مقالهی "Serverها باهم چه تفاوتی دارند"[1] به برخی از تجهیزات سختافزاری و تکنولوژیهایی که در انجام این کار به کمک چنین سازمانهایی میآیند اشاره کردیم. حال در این مقاله به جزئیات بیشتری (و البته تنها به بحث دربارهی گوگل) میپردازیم.
بیایید ابتدا مشکل را پیدا کنیم: متوسط زمان پویش دادهها[2] در بهترین دیسکهای سخت موجود حدود 4میلی ثانیه است. زمانی که انسان به عنوان "لحظه" درنظر دارد حدود 50میلی ثانیه است. حال اگر شما فقط به یک پویش برای هر درخواست کاربران احتیاج داشته باشید، قبل از اینکه کاربری اعلام کندی سرعت کند، تنها12 درخواست را میتوانید جوابگو باشید. اگر برنامهی مدیریت پروندهها[3] و بانک اطلاعاتی را نیز اضافه کنید، این مقدار به یک سوم کاهش مییابد. درضمن نگهداری اطلاعات درخواستی در حافظهی نهانگاهی[4] نیز کمکی نمیکند، چرا که تنها به درد نفر دوم میخورد و وقتی که با میلیونها نفر در روز که هرکدام درخواست مخصوص خود را دارند سرکار دارید، کاربردی ندارد.
و اما راهحل: شاید باورکردن آن مشکل باشد اما.... همان گونه که سرویس "پیام فوری" شرکت AOL®[5] تمام پیامها را در حافظهی اصلی(RAM) "خدماترسان"یا Server های خود نگه میدارد، گوگل نیز از دیسکهای سخت خود فقط برای اجراشدن سیستمعامل و برنامههای مورد نیاز(به اصطلاح برای Bootشدن) استفاده میکند و تمام اطلاعات مربوط به جستوجو را در حافظهی اصلی(RAM) نگه میدارد!!
اگر دقت کرده باشید، وقتی گوگل سایتی را که با شرایط جستوجوی شما همخوانی دارد پیدا میکند، بخشهایی از سایت که دارای کلمات مورد نظرهستند را نیز نمایش میدهد. این درحالی است که سایر موتورهای جستوجو تنها چند جمله از اول صفحهی مورد نظر را نشان میدهند.
برای انجام چنین کاری، گوگل باید یک ( و حداقل یک) کپی از آن صفحه را دراختیار داشته باشد. این بدان معنی است که گوگل چندین[6] کپی از تمام وب در حافظهی Serverهای خود دارد[7].
گوگل غیر از جستوجوی سریع چه دارد؟
قدرت موتور جستوجوی گوگل نه تنها در زمان پایین جستوجوهای آن، بلکه در تعداد صفحاتی است که به عنوان نتیجه بر میگرداند.
گوگل وب را به دنبال صفحات جدید میگردد و یک کپی از آنها را به بانک خود اضافه میکند[8]. پس اگر هنگامی که به دنبال موضوعی بودید و سایت خود را در لیست سایتهای نتیجهی جستوجو یافتید، درحالی که آن را بصورت دستی به بانک گوگل اضافه نکرده بودید، تعجب نکنید (البته تعجب کنید چون جای تعجب دارد ولی دلیلش را بدانید).
سرویس جستوجوی باور نکردنی گوگل با سرویس پست الکترونیکی جدیدش باورنکردنیتر میشود. با راهاندازی این سرویس بنظر میرسد گوگل نهتنها قصد از راه به در کردن، بلکه شاید "له کردن" رقبا را در سر میپروراند. درحالی که Yahoo® با کاهش حجم جعبههای پستی[9] رایگان از 6مگابایت به 4مگابایت و خارج کردن سرویس POP3 از لیست سرویسهای رایگان، کاربران اش را به سمت سرویسهای غیر رایگان سوق میدهد، گوگل با دست و دلبازی تمام، درنظر دارد به هر جعبه پستی 1.000مگابایت فضا اختصاص دهد. البته درمورد سرویس POP3 اعلام کرده که هنوز برای راهاندازیاش تصمیمی نگرفته است.
برای نگهداری این اطلاعات، گوگل از یک تیم خبرهِی برنامه نویس برای ابداع یک File System مخصوص بهره گرفته است. این تیم، نتیجهی تحقیقات 10سال اخیر دانشگاهها را در زمینهی نرمافزار بهخدمت گرفتند تا یک روش نگهداری، بازیابی و پردازش اطلاعات غیرمتمرکز را به وجود بیاورند.
Hot Mail™، 60میلیون کاربر دارد. گوگل را باید برای 100میلیون کاربر درنظر بگیریم (هرچند کمکم به این مقدار برسد). واضحترین مسئله این است که شما نمیتوانید اطلاعات کاربرانتان را از دست بدهید، در ضمن نمیخواهید که هیچگاه در دسترس نباشید، پس باید اطلاعات را Replicateکنید. RAID هم پیشنهاد خوبی نیست، اگر یک دیسک خراب شود، به یک نفر برای تعویض آن نیاز دارید و اگر بیش از یک دیسک خراب شود احتمال از دست دادن اطلاعات را خواهید داشت. درضمن به سختافزارهای گرانی نیز احتیاج دارد. مهمتر از همهی اینها RAID دردسترس بودن را در سطح Server تضمین نمیکند(در سطح دیسک سخت تضمین میکند).
گوگل به کمک File System ابداعی خود، اطلاعات را در 3 محل نگهداری میکند. اگر یکی از Serverها(یا دیسکها) از کار بیافتند، آن را به همان حال رها میکنند تا در دورههای بازدیدی، تعمیر/تعویض شود. درعوض این از کارافتادگی را از طریق نرمافزاری و بصورت خودکار جبران میکنند. با از کار افتادن یکی از 3بخش نگهداری اطلاعات، یک کپی از دوبخش باقی مانده گرفته شده و پس از فشرده سازی 3به1، در محل جدیدی نگهداری میگردد.
مشکل Serverهای گوگل تنها ظرفیت دیسکهای نیست، بلکه پردازندههای آنها نیز بصورت دایم مشغول فهرست گذاری(Indexing) اطلاعات هستند. هر واحد از Serverهای گوگل تنها 1یا2 دیسک سخت دارد(بدون هیچ RAID Controllerای).
بخاطر این ابعاد گسترده و با توجه به نرمافزار مخصوص تهیه شده، هزینهی هر گیگابایت فضا برای کاربران حدود 2دلار برآورد میشود.
با تمام حرفها و حدیثهایی که دربارهی توقف یا به مرحلهی اجرا رسیدن این پروژه وجود دارد، بنظر نگارنده هیچچیز نمیتواند قدرت چنین فناوری را زیر سئوال ببرد.
برگرفته از:
http://www.google.com
1 جالب است بدانید که گوگل خیلی به استفاده از آن Serverهای گرانقیمت اعتقاد ندارد و از آنها چندان بهره نمیگیرد!!
2 Data Seek Time
3 File System Manager
4 Caching
5 AIM™: AOL® Instant Messages
6 اطلاعات در چندین محل نگهداری میشوند سپس بکمک سرویسهایی موسوم به سرویسهای "خوشهای"(Clustering) تمام این چند محل، بصورت یک واحد نمایان میشوند.
7 This means that Google™ is currently storing multiple copies of web in RAM
8 We add and update new sites to our index each time we crawl the web.
9 Mailbox
روشهاى ارتباط بين پردازشها در UNIX
يکى از مهمترين مقولههاى مطرح در مورد سيستمهاى عاملى که در آنها مفهوم پردازش۱ وجود دارد، برقرارى ارتباط بين پردازشها۲ يا IPC است. معمولا در سيستمهاى عامل مختلف، روشهاى مختلفى براى اين منظور وجود دارد. در اين نوشتار سعى داريم دو روش از روشهاى برقرارى ارتباط بين پردازشهاى مختلف در سيستم عامل UNIX را تشريح کنيم. نخست نگاهى داريم بر روشهاى مختلف IPC در UNIX. پس از آن هر يک از دو روش سمافور و حافظهى مشترک را به طور جداگانه بررسى خواهيم کرد.
روشهاى ارتباط بين پردازشها در UNIX
روشهاى مختلفى براى ارتباط بين پردازشها در UNIX وجود دارد. اين روشها عبارتند از:
در بين روشهاى فوق، روشهاى شماره ۴، ۵، و ۶ به روشهاى IPC در System V موسومند. روشهاى ۱ و ۲ تنها براى ارتباط بين دو پردازش که متعلق به يک کاربر هستند به کار مىروند و بقيه روشها مىتوانند براى ارتباط بين دو پردازش که متعلق به يک کاربر نيستند نيز به کار روند. در بين اين روشها، استفاده از سمافور براى هماهنگ کردن دو پردازش بدون Busy Waiting و استفاده از حافظه مشترک براى انتقال مقدار زياد داده بسيار معمول هستند. همين طور روش ۷ نيز در طراحى نرمافزارهاى شبکه بسيار استفاده مىشود.
روشهاى IPC در Message Queue) System V، سمافور، و حافظه مشترک) شباهتهاى زيادى در زمينه اطلاعاتى که هسته۴ سيستم عامل در مورد آنها نگهدارى مىکند و فراخوانىهاى سيستم لازم براى دستيابى به آنها دارند. در اين بخش برخى از ساختارهاى مشترک بين اين روشها را بررسى خواهيم کرد.
هسته UNIX همانطور که در مورد هر فايل اطلاعاتى را نگهدارى مىکند، در مورد هر کانال IPC (که مىتواند Message Queue، سمافور، و يا حافظه مشترک باشد) نيز اطلاعات زير را نگه مىدارد.
struct ipc_perm {
ushort uid; /* owner's user id */
ushort gid; /* owner's group id */
ushort cuid; /* creator's user id */
ushort cgid; /* creator's group id */
ushort mode; /* access modes */
ushort seq; /* slot usage sequence number */
key_t key; /* key */
};
اين ساختار در msgctl (در مورد Message Queue)، semctl (در مورد سمافور)، و shmctl (در مورد حافظه مشترک) مىتوان به اين ساختار دسترسى پيدا کرد و يا آن را تغيير داد.
در بين فيلدهاى اين ساختار، فيلدى به نام key ديده مىشود. اهميت اين فيلد براى کانالهاى IPC، مانند اهميت اسم براى فايل است؛ همانطور که هر فايلى با يک اسم شناخته مىشود، هر کانال IPC نيز با يک کليد ( key ) شناخته مىشود. کليد يک عدد صحيح ۳۲ بيتى است که دو پردازش که مىخواهند از طريق يک کانال IPC مشترک ارتباط داشته باشند، بايد از قبل روى يک کليد توافق کرده باشند و هر دوى آنها کانالى با آن کليد مشخص را باز کنند. البته اين مشکل وجود دارد که در صورتى که پردازش ديگرى نيز بخواهد يک کانال IPC با همان کليد بگيرد، کار اين پردازشها با هم تداخل پيدا خواهد کرد.
هر پردازش مىتواند در هنگام گرفتن کانال IPC، مقدار کليد را برابر با IPC_PRIVATE مشخص کند. در اين صورت يک کانال منحصر به فرد براى اين پردازش ايجاد خواهد شد. البته اگر بخواهيم از اين کانال براى ارتباط بين دو پردازش استفاده کنيم، بايد مشخصات کانال گرفته شده را با استفاده از روش ديگرى به پردازش طرف ارتباط اطلاع دهيم. استفاده از امکان مشخص کردن کليد به صورت IPC_PRIVATE ، به خصوص در مواردى کاربرد دارد که دو پردازشى که مىخواهند با هم ارتباط برقرار کنند، پردازشهايى باشند که در اثر fork کردن، از يک پردازش ايجاد شده باشند. در اين صورت کافى است قبل از انجام عمل fork ، کانال ارتباطى با کليد IPC_PRIVATE گرفته شود و پس از fork کردن، دو پردازش از آن استفاده کنند.
|