| تبليغات | X |
|
XGRID تکنولوژی
|
||
|
پیاده سازی سیستم های توزیع شده |
نخستين ابررايانه قابل انطباق جهان
سريعترين و قدرتمندترين ابررايانه جهان با نام Novo-G در دانشگاه فلوريداي ايالات متحده امريکا راهاندازي شد.
به گزارش «اعتماد»، قسمت اول نام اين ابررايانه از واژهاي لاتين به مفهوم «ايجاد تغيير» برگرفته شده و قسمت دوم آن از واژه Genesis به مفهوم قابل انطباق و به منظور شرح توانايي رايانهاي با توانايي بازسازماندهي مدارهاي داخلي براي انطباق با دستور ارائه شده انتخاب شده است.
«آلن جرج» پروفسور مرکز بنياد علوم ملي محاسبات رايانهاي قابل انطباق با عملکرد بالا در دانشگاه کاليفرنيا (NSF) معتقد است اين ابررايانه ميتواند با محدوده اطلاعات دريافت شده از ماهوارههاي فضايي تا ديگر ابررايانهها در ارتباط بوده و پردازش آنها را بر عهده داشته باشد. به گفته وي Novo-G فناوري بسيار قدرتمند و در عين حال پيچيده است و به همين دليل نبايد امکان استفاده از چنين سيستمي تنها در انحصار متخصصان قرار گيرد.
به گفته متخصصان استفاده از رايانههاي رايج براي پردازش حجم عظيمي از اطلاعات بدون توجه به نوع درخواست کاربر، نيازمند فضا و انرژي بسياري خواهد بود. در عين حال رايانههاي خاص به گونهاي ساخته ميشوند تا تنها بتوانند وظايف ثابت و تعيين شدهاي را به انجام برسانند و از هيچ انعطاف پذيري عملياتي برخوردار نيستند.
اما استفاده از رايانههاي قابل انعطاف ميتواند بهترين عملکرد و نتيجه را در هر زمينه تحقيقاتي و پردازش اطلاعات به وجود آورد. اين به آن دليل است که اين رايانهها ميتوانند مدارهاي داخلي خود را مشابه آجرهاي بازي لگو بازسازماندهي کنند تا ساختار داخلي خود را با نياز موجود براي انجام دستور ارائه شده انطباق دهند.
سرعت عملياتي اين رايانهها نسبت به رايانههاي رايج 10 تا 100 بار سريع تر است در حالي که ميزان انرژي مورد استفاده آنها 10 بار کمتر از ديگر رايانهها است. به گزارش مهر با وجود اينکه ابررايانه Novo-G عملکرد خود را به اثبات رسانده است رايانههاي قابل انطباق در مرحله تحقيقاتي باقي ماندهاند و استفاده از آنها براي بسياري از کاربران پيچيده و دشوار به شمار ميرود. يکي از اصلي ترين اهداف موسسه NSF بهبود دادن فناوري رايانههاي قابل انطباق و افزايش ميزان دسترسي به اين رايانهها براي کاربران مختلف اعلام شده است.
منبع : http://tabnak.ir
باز هم تأخير در پيچيدهترين پروژه تاريخ بشر
ابرکامپیوتر 20 پتافلاپي آمد
سازندگان ابرکامپیوترها سالهاست بر سر ساخت قویترین کامپیوتر جهان رقابت میکنند
ولی سرانجام شركت آيبيام (IBM) در روز 15 بهمن، قویترین ابرکامپیوتر جهان به نام Sequoia را معرفی کرد. این ابرکامپیوتر 20 برابر قویتر از کامپیوتر رکورددار قبلی است.
Sequoia توانایی انجام 20 کوادریلیون (1015) محاسبه در هر ثانیه (20 پتافلاپ) را خواهد داشت. این مقدار تقریباً معادل قدرت محاسبه بیش از 2 میلیون لپتاپ ساده است.
بیش از 1.6 میلیون قطعه در این کامپیوتر، سرعتی به مراتب بالاتر از ابر کامپیوتر 1.1 پتافلاپی Blue Gene/L را به Sequoia میدهد.
این ابر کامپیوتر به سفارش وزارت انرژی آمریکا ساخته شدهاست و انتظار میرود که تا سال 2012 در لابراتوار ملی لاورنس لیورمور در کالیفرنیا نصب و راهاندازی شود. این لابراتوار بزگترین مرکز تحقیقات انرژی هستهای، حفاظت از محیط زیست و مسائل اقتصادی مرتبط با انرژی است.
Sequioa به همراه کامپیوتر دیگری به نام Dawn در این لابراتوار برای شبیه سازی چرخه تولید انرژی از سوخت هستهای مورد استفاده قرار میگیرد.
توانایی ابر کامپیوترها در رسیدن به سرعتهای بسیار بالا مدیون استفاده از فنآوریهای پیشرفته و ارزان توسط دانشمندان است. سرعت محاسبه یک تریلیون در هر ثانیه در علوم کامپیوتر به ترافلاپ (TeraFlop) معروف است و اولین کامپیوتری که رکورد این سرعت را شکست محصول سال 1996 میباشد.
دو سال پیش، کامپیوتر 59 میلیون دلاری ساخت شرکت سان مایکروسیستم به نام Constellation به سرعت 421 تریلیون محاسبه در هر ثانیه رسید.
شركت آيبيام همچنین خبر دادهاست که نسل بعدی ابرکامپیوترها به محدوده سرعت اکسافلاپ (Exaflop) یا 1018 محاسبه در هر ثانیه خواهد رسید.
منبع : http://tabnak.ir
استاد ايراني دانشگاه واشنگتن ابررايانهاي استثنايي طراحي كرد
عرضه نخستين تراشههاي شش هستهای اينتل
اينتل با به نمايش گذاشتن ريزپردازندههاي چندهستهيي كه ضمن بالا بردن قدرت رايانش استفاده از برق را كاهش ميدهند، نخستين تراشه هاي شش هستهيي خود را عرضه كرد.
به گزارش ايسنا، اينتل و Advanced Micro Devices، شركت رقيب آن تراشه هاي دو و چهار هستهيي در بازار داشتهاند.
طبق اظهار معاون گروه اينترپرايز اينتل، تراشهي شش هستهيي 50 درصد كارآمدي بيشتر نسبت به مدلهاي چهار هستهيي داشته و در عين حال 10 درصد كمتر برق مصرف ميكنند؛ هزينههاي برق و خنكسازي تقريبا نيمي از هزينههاي ادارهي سرورهاي رايانهيي شركتها محسوب ميشوند.
تراشههاي چندهستهيي معروف به مولتي كور براي گرايشهاي رايانشي از جمله مشاهدهي ويديوي كيفيت بالاي آنلاين، سرويسهاي كاربردي كه شركتها در اينترنت عرضه ميكنند و سرورهايي كه دستگاههاي مجازي زيادي برروي آنها كار ميكنند، بسيار مفيد هستند.
تراشههاي چندهستهيي به رايانهها امكان ميدهند همزمان به پردازش وظايف متعددي بپردازند؛ تراشهي Xeon 7400 جديد در سرورهاي ويژهي شبكههاي سازماني شركتهاي دل، هيولت پاكارد، آي بي ام، يوني سيس و فوجيتسو به كار خواهد رفت.
منبع : http://www.tabnak.ir
مراحل ایجاد یک برنامه client/server در دلفی
بسمه تعالی
مراحل ایجاد یک برنامه clint/server
توضیح : خیلی از عزیزان برای شبکه کردن indy را توصیه می کنند . درست است INDY برای ارسال پیام در شبکه و ایمیل و ... مناسب است ولی برای بانکهای اطلاعاتی درد سر بسیار دارد . در این ثال از datasnap استفاده شده که کار را بسیار راحت می کند .
الف : برنامه سرور
1-یک پروژه جدید باز کنید و با عنوان سرور ذخیره نمایید
2- به قسمت file / new / other/multitier رفته و بر روی remote data server کلیک نمایید
3- حال یک پنجره با عنوان remote data module wizard ایجاد می شود که در قسمت CoClass Name یک نام برای سرور انتخاب نمایید . و به قسمتهای دیگر کاری نداشته باشید و ok را بزنید .
4- بلافاصله یک datamodule جدید با نام سرور (نامی که در قسمت class name انتخاب نمودید ) ایجاد می شود .
5- حال با استفاده از ado یا bde یا ... به با نک اطلاعاتی وصل شوید . مثلا با adoquery به یک جدول از یک بانک اطلاعاتی sql server وصل شده . حال adoqueryr را فعال سازید تا ارتباط برقرار شود . در پنجره مشخصات adoquery خاصیت active را true نمایید .
6- در قسمت dataacess یک DataSetProvider1 را بر روی datamoule که ایجاد کرده ایم قرار می دهیم و روی dataset در پنجره مشخصات کلیک نموده تا نام ارتباط بانک اطلاعاتی نمایان شود ( adoquer در مثال بالا)
7- پس از اطمینال از اتصال صحیح با نک اطلاعاتی پروژه را ذخیره و یک بار اجرا نمایید تا سرور در شبکه ثبت شود .
8- توجه داشته باشید که برنامه سرور فقط محل نگهداری بانک اطلاعاتی و کنترل اتصالات و کاربران است . پس کار دیگری را انجام نمی دهیم و حال فایل اجرایی برنامه سرور را اجرا می کنم.
ب نوشتن برنامه کلاینت
1- یک پروژه جدید با عنوان کلاینت ایجاد نموده و ذخیره نمایید .
2- در روی فرم از قسمت datasnap یک SocketConnection1 را روی فرم قرار داه . در قسمت adress نام ip کامپیوتر سرور را وارد نمایید.(مثلا ip سرور در برنامه محل کار من 10.20.1.93 است ) . اگر ای پی سرور را نمی دانید می توانید نام کامپیوتر سرور را وارد کنید .حال در قسمت servername نام سروری را که در برنامه سرور ثبت کرده اید را انتخاب نمایید . اگه پیام خطا داده احتمالا در تنظیمات شبکه یا خود شبکه ایراد است . وقتی نام سرور را نتخاب کردید گزینه conecct از مشخصات SocketConnection1 vh را true کنید . اگر true شد یعنی ارتنباط با سرور بر قرا است .
3- حال در قسمت datascess یک ClientDataSet1 بر روی فرم قرار داده و تنظیمات زیر را انجام دهید
A: در قسمت remote server کلیک نمایید تا نام socketConnection1 ظاهر شود .
b: در قسمت provider name کلیک کنید تا نام DataSetProvider1 ظاهر شود
c:حال خاصیت active را true کنید .
4- حال از قسمت dataascess یک datasource1 بر روی فرم قرار دهید و خاصیت datadet آن را با نام clientdataset1ظاهر شود .
5- حال از قسمت data control یک datagrid روی فرم قرار داده و خاصیت datasource آن رو datasource 1 انتخاب کنید . می بینید که اطلاعات سرور نمایش داده می شود .
توضیحات . چون ما از SocketConnection2 استفاده می کنیدم که بر اساس tcp/ip عمل می کنید (پشتیبانی سوکت ها ) باید برنامه فعال سوکت ها فعال شود . برای این کار مرحل زیر را انجام دهید
1- در قسمت run ویندوز دستور cmd را تایپ نمایید .
2- پس از ورود به محیط cmd دستور مقابل را تایپ نمایید scktsrvr - install .
توضیح 2 : فرض بر این است که کلیه خوانندگان عزیز با بانک اطلاعتی و ارتباط با ان آشنایی دارند . اگر می خواهید به نتیجه برسید نامگذاری اشیاعی که بر روی فرم ها و ... می گذارید عین مثال باشد .
امیدوارم مورد استفاده قرار گرفته باشد .
منبع : http://delphi-7.blogfa.com
ساخت سریع ترین رایانه جهان در آمریکا
دانشمندان آمریکایی در آزمایشگاه دولتی اسلحه «لوس آلاموس»، موفق به ساخت پر شتاب ترین کامپیوتر جهان موسوم به «رودرانر» شدهاند.
به گزارش سرویس علم و فن آوری آفتاب، این رایانه توانایی انجام 1000 تریلیون عملیات در ثانیه را داراست.
دانشکده انرژی موسسه IBM روز دوشنبه با اعلام این خبر افزود که این کامپیوتر قرار است برای یاری به برنامه ملی جمع آوری سلاح های هسته ای مورد استفاده قرار گیرد.
«سمیوئل بادمن» سخنگوی دانشکده انرژی در این باره اظهار داشت: « این کامپیوتر موسوم به رودرانر ( roadrunner )همچنین قرار است برای یافتن پاسخ برای مشکلات انرژی جهانی و گشودن درهای تازه به سوی دانش در پژوهش های بنیادی به کار گرفته شود.
منبع : http://www.aftabnews.ir/vdcdk50ytx095.html
Using DRMAA with Unicluster Express
Distributed Resource Management Application API (DRMAA) is a high-level API that allows Grid applications to submit, monitor and control jobs to one or more DRM systems. Grid Engine comes with support for C/C++ and java, and one can also download bindings for ruby and python. There is also a nice collection of HowTos that should provide a great start for anyone looking to start writing DRMAA applications. The latest version of Unicluster Express (UCE) bundles Grid Engine 6.1u3, which is installed under $GLOBUS_LOCATION/sge. The $GLOBUS_LOCATION refers to the UCE installation directory (/usr/local/unicluster by default), and all of the DRMAA libraries and java files are located in the $GLOBUS_LOCATION/sge/lib directory. In order to run DRMAA applications, one has to set $LD_LIBRARY_PATH to point to the appropriate (architecture dependent) directory. For my development (64-bit linux) cluster with default UCE installation I used the following setup:
$ source /usr/local/unicluster/unicluster-user-env.sh $ export LD_LIBRARY_PATH=/usr/local/unicluster/sge/lib/lx24-amd64 $ export JAVA_HOME=/opt/jdk $ export PATH=$JAVA_HOME/bin:$PATH
A very simple example of a java DRMAA application that submits a job to Grid Engine is shown below:
$ cat SimpleJob.java
import org.ggf.drmaa.DrmaaException;
import org.ggf.drmaa.JobTemplate;
import org.ggf.drmaa.Session;
import org.ggf.drmaa.SessionFactory;
public class SimpleJob {
public static void main(String[] args) {
SessionFactory factory = SessionFactory.getFactory();
Session session = factory.getSession();
try {
session.init("");
JobTemplate jt = session.createJobTemplate();
jt.setRemoteCommand("/home/veseli/simple_job.sh");
String id = session.runJob(jt);
System.out.println("Your job has been submitted with id " + id);
}
catch (DrmaaException e) {
System.out.println("Error: " + e.getMessage());
}
}
}
One can compile and run the above example using something like the following:
$ javac -classpath /usr/local/unicluster/sge/lib/drmaa.jar SimpleJob.java $ java -classpath .:/usr/local/unicluster/sge/lib/drmaa.jar SimpleJob Your job has been submitted with id 14 $ qstat -f queuename qtype used/tot. load_avg arch states ---------------------------------------------------------------------------- all.q@horatio.psvm.univa.com BP 1/1 0.36 lx24-amd64 14 0.55500 simple_job veseli r 06/20/2008 12:24:59 1 ---------------------------------------------------------------------------- all.q@romeo.psvm.univa.com BP 0/1 0.39 lx24-amd64 ---------------------------------------------------------------------------- all.q@yorick.psvm.univa.com BP 0/1 0.45 lx24-amd64 ---------------------------------------------------------------------------- headnodes.q@petruchio.psvm.uni IP 0/1 0.15 lx24-amd64 ---------------------------------------------------------------------------- special.q@horatio.psvm.univa.c BIP 0/1 0.36 lx24-amd64
I should point out that DRMAA is designed to be independent of any particular DRM. Those users that need job submission features or flags specific to Grid Engine can either use the “native specification” attribute, or they can use the “job category” attribute together with “qtask” files. In order to set native specification attribute in java one would use setNativeSpecification() method of the JobTemplate class (before the job submission line in the code):
jt.setNativeSpecification("-q special.q");
This method, however, makes your application dependent on the specific DRM you are working with at the moment. The above line will be interpreted correctly by Grid Engine, but may not be understood by other DRMs. In most cases a better solution is to use the job category attribute instead, and specify the DRM-dependent flags in the qtask file. For example, in order to submit your job to a particular Grid Engine queue in the java code one would have something like
jt.setJobCategory("special");
and use the qtask file to translate the “special” job category into appropriate Grid Engine flags:
$ cat ~/.qtask special -q special.q
The cluster global qtask file (defines cluster wide defaults) in UCE resides at $GLOBUS_LOCATION/sge/default/common/qtask. As shown above, user-specific qtask files that override and enhance cluster-wide definitions are found at ~/.qtask.
منبع : http://gridgurus.typepad.com
Aromatic Clouds?
If you weren’t at OSGC you missed a number of interesting presentations. From my perspective, one of the most intriguing technologies was EUCALYPTUS: Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems.
Before I go on, I would like you to notice that anybody who is able to make an acronym out of eucalyptus has some time on their hands. Fortunately, they used this time to implement an open-source infrastructure for Elastic Computing. In particular, the goal of the project is to, "foster community research and development of Elastic/Utility/Cloud service implementation technologies, resource allocation strategies, service level agreement (SLA) mechanisms and policies, and usage models."
In my opinion, the most interesting facets of this project are:
My hope is that this project will not only get us all thinking about what we really need from a Cloud but also what we could improve... I plan to start working with this software as soon as it is available later this month.
منبع : http://gridgurus.typepad.com
 |
ابر رايانه به تشخيص پوکي استخوان کمک مي کند
تهران-خبرگزاری جمهوری اسلامی (ایرنا): دانشمندان سوييسي از دستاورد جديدي در شبيه سازي ابر رايانه اي خبر دادند که مي تواند تا اندازه زيادي به تشخيص و درمان پوکي استخوان کمک کند. |
به گزارش خبرگزاري يونايتدپرس، در حاليکه پوکي يا کاهش تراکم استخوان همراه با افزايش خطر شکستگي معمولا در مراحل پيشرفته تشخيص داده مي شود، محققان "موسسه فناوري سوييس" و " آزمايشگاه تحقيقاتي IBM زوريخ" گفتند، تنها در چند دقيقه جامع ترين شبيه سازي ساختارهاي استخواني انسان را نشان دادند.
دانشمندان گفتند که دستاورد آنها مي تواند به ساخت ابزارهاي باليني بهتري براي تشخيص و درمان عارضه پوکي استخوان منجر شود که شايع ترين بيماري استخواني است .
IBM همچنين در بيانيه اي اعلام کرد: با اين شبيه سازي ها محققان مي توانند نوعي "نقشه حرارتي " پويا از استحکام استخوان تهيه کنند که دقيقا نشان مي دهد کجا ساختار استخوان آسيب مي بيند و احتمالا چه باري موجب شکستگي مي شود.
برپايه اين بيانيه، از چنين شبيه سازي هاي قوي مي توان مرتب در توموگرافي هاي آتي رايانه اي استفاده کرد و اين شبيه سازي ها توانايي پزشکان را براي تجزيه و تحليل خطر شکستگي ها افزايش مي دهد و از اين رو موجب بهبود درمان مي شود.
About Grid Engine Advanced Reservations
Advanced reservation (AR) capability is one of the most important new features of the upcoming Grid Engine 6.2 release. New command line utilities allow users and administrators to submit resource reservations (qrsub), view granted reservations (qrstat), or delete reservations (qrdel). Also, some of the existing commands are getting new switches. For example, the “-ar
$ qconf -sul arusers deadlineusers defaultdepartment
$ qconf -su arusers name arusers type ACL fshare 0 oticket 0 entries NONE
The “arusers” ACL can be modified via the “qconf -mu” command:
$ qconf -mu arusers veseli@tolkien.ps.uud.com modified "arusers" in userset list
$ qconf -su arusers name arusers type ACL fshare 0 oticket 0 entries veseli
Once designated as a member of this list, the user is allowed to submit ARs to Grid Engine:
[veseli@tolkien]$ qrsub -e 0805141450.33 -pe mpi 2 Your advance reservation 3 has been granted
[veseli@tolkien]$ qrstat
ar-id name owner state start at end at duration
-----------------------------------------------------------------------------------------
3 veseli r 05/14/2008 14:33:08 05/14/2008 14:50:33 00:17:25
[veseli@tolkien]$ qstat -f queuename qtype resv/used/tot. load_avg arch states --------------------------------------------------------------------------------- all.q@tolkien.ps.uud.com BIP 2/0/4 0.04 lx24-x86
For the sake of simplicity, in the above example we have a single queue (all.q) that has 4 job slots and a parallel environment (PE) mpi assigned to it. After reserving 2 slots for the mpi PE, there are only 2 slots left for running regular jobs until the above shown AR expires. Note that the "–e" switch for qrsub designates requested reservation end time in the format YYMMDDhhmm.ss. It is also worth pointing out that the qstat output changed slightly with respect to previous software releases in order to accommodate display of existing reservations. If we now submit several regular jobs, only 2 of them will be able to run:
[veseli@tolkien]$ qsub regular_job.sh
Your job 15 ("regular_job.sh") has been submitted
...
[veseli@tolkien]$ qsub regular_job.sh
Your job 19 ("regular_job.sh") has been submitted
[veseli@tolkien]$ qstat -f
queuename qtype resv/used/tot. load_avg arch states
---------------------------------------------------------------------------------
all.q@tolkien.ps.uud.com BIP 2/2/4 0.03 lx24-x86
15 0.55500 regular_jo veseli r 05/14/2008 14:34:32 1
16 0.55500 regular_jo veseli r 05/14/2008 14:34:32 1
############################################################################
- PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS
############################################################################
17 0.55500 regular_jo veseli qw 05/14/2008 14:34:22 1
18 0.55500 regular_jo veseli qw 05/14/2008 14:34:23 1
19 0.55500 regular_jo veseli qw 05/14/2008 14:34:24 1
However, if we submit jobs that are part of the existing AR, those are allowed to run, while jobs submitted earlier are still pending:
[veseli@tolkien]$ qsub -ar 3 reserved_job.sh
Your job 20 ("reserved_job.sh") has been submitted
[veseli@tolkien]$ qsub -ar 3 reserved_job.sh
Your job 21 ("reserved_job.sh") has been submitted
[veseli@tolkien]$ qstat -f
queuename qtype resv/used/tot. load_avg arch states
---------------------------------------------------------------------------------
all.q@tolkien.ps.uud.com BIP 2/4/4 0.02 lx24-x86
15 0.55500 regular_jo veseli r 05/14/2008 14:34:32 1
16 0.55500 regular_jo veseli r 05/14/2008 14:34:32 1
20 0.55500 reserved_j veseli r 05/14/2008 14:35:02 1
21 0.55500 reserved_j veseli r 05/14/2008 14:35:02 1
############################################################################
- PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS
############################################################################
17 0.55500 regular_jo veseli qw 05/14/2008 14:34:22 1
18 0.55500 regular_jo veseli qw 05/14/2008 14:34:23 1
19 0.55500 regular_jo veseli qw 05/14/2008 14:34:24 1
The above example illustrates how ARs work. As long as particular reservation is valid, only jobs that are designated as part of it can utilize resources that have been reserved. I think that AR will prove to be extremely valuable tool for planning grid resource usage, and I’m very pleased to see it in the new Grid Engine release.
منبع : http://gridgurus.typepad.com
Steaming Java
When Rich asked us to walk through a software development process, I immediately thought back to a conversation that I had with my friend Leif Wickland about building high-performance Java applications. So I immediately emailed him asking him for his best practices. We have both produced code that is as fast, if not faster than C compiled with optimization (for me it was using a 64-bit JRE on a x86_64 architecture with multiple cores).
That is not to say that if you were to spend time optimizing the equivalent C-code that it would not be made to go faster. Rather, the main point is that Java is a viable HPC language. On a related note, Brian Goetz of Sun has a very interesting discussion on IBM's DeveloperWorks, Urban performance legends, revisited on how garbage collection allows faster raw allocation performance.
However I digress… Here is a summary of what we both came up with (in no particular order):
منبع : http://gridgurus.typepad.com
Grid Interoperability and Interoperation
The high expectations raised by grid computing have favored the development and deployment of a growing number of grid infrastructures and middlewares. However, the interaction between these grids is still limited, so reducing the potential large-scale application of grid technology, in spite of efforts made by grid community. In this sense, the Open Grid Forum (OGF) is developing open standards for grid software interoperability, while the OGF's Grid Interoperation Now Community Group (GIN-CG) is coordinating a set of interoperation efforts among production grids. It is therefore clear that, according to OGF (as Laurence Field explains in his article entitled "Getting Grids to work together: interoperation is key to sharing"), there is a big difference between these two terms:
Since most common open standards to provide grid interoperability are still being defined and only a few have been consolidated, grid interoperation techniques, like adapters and gateways, are needed. An adapter is, according to different dictionaries of computer terms, “a device that allows one system to connect to and work with another”. On the other hand, a gateway is conceptually similar to an adapter, but it is implemented as an independent service, acting as a bridge between two systems. The main drawback of adapters is that grid middleware or tools must be modified to insert the adapters. Gateways can be accessed without changes on grid middleware or tools, but they can become a single point of failure or a scalability bottleneck.
GridWay provides support for some of the few established standards like DRMAA, JSDL or WSRF to achieve interoperability but, in the meanwhile, it also provides components to allow interoperation, like Middleware Access Drivers (MADs) acting as adapters for different grid services, and the GridGateWay, which is a WSRF GRAM service encapsulating an instance of GridWay, thus providing a gateway for resource management services.
GridWay 4.0.2, coinciding with the release of Globus Toolkit 4 and its new WS GRAM service, introduced an architecture for the execution manager module based on a MAD (Middleware Access Driver) to interface several grid execution services, like pre-WS GRAM and WS GRAM, even simultaneously. That architecture was presented in the paper entitled "A modular meta-scheduling architecture for interfacing with pre-WS and WS Grid resource management services" (E. Huedo, R. S. Montero and I. M. Llorente). GridWay 5.0 took advantage of this modular architecture to implement an information manager module with a MAD to interface several grid information services, and a transfer manager module with a MAD to interface several grid data services. Moreover, the scheduling process was decoupled from the dispatch manager through the use of an external and selectable scheduler module.
The resulting architecture, which is shown above, provides direct interoperation between different middleware stacks. In fact, we demonstrated at OGF22 the interoperation of three important grid infrastructures, namely EGEE (gLite-based), TeraGrid and OSG (both Globus-based), being coordinately used through a single GridWay instance by means of the appropriate adapters. To set an example, the application was written using the DRMAA OGF standard. GridWay documentation provides a lot of information on how to integrate GridWay in the main middleware stacks, like gLite, pre-WS and WS Globus, or ARC, and provides information on how to develop new drivers for other middlewares.
Regarding the GridGateWay, it is being used for provisioning resources from several infrastructures. For example, the German Astronomy Community Grid (GACG or AstroGrid-D) uses a GridGateWay as a central resource broker, providing metascheduling functionality to Globus-based submission tools (e.g. for workflow execution) without modification. GridAustralia also uses a GridGateWay as a WSRF interface for its central GridWay Metascheduler instance, allowing reliable, remote job submission.
Picture by AstroGrid-D
More information about the GridGateWay component is provided in its web page, as well as in this blog entry, which shows how to build Utility Computing infrastructures with this Globus-based gateway technology.
Reprinted from blog.dsa-research.org
منبع : http://gridgurus.typepad.com
Grid Engine 6.2 Beta Release
Grid Engine 6.2 will come with some interesting new features. In addition to advance resource reservations and array job interdependencies, this release will also contain a new Service Domain Manager (SDM) module, which will allow distributing computational resources between different services, such as different Grid Engine clusters or application servers. For example, SDM will be able to withdraw unneeded machines from one cluster (or application server) and assign it to a different one or keep it in its “spare resource pool”. It is also worth mentioning that Grid Engine (and SDM) documentation is moving to Sun’s wiki. The 6.2 beta release is available for download here.
منبع : http://gridgurus.typepad.com
Support for parallel jobs in distributed resource management software is probably one of those features that most people do not use, but those who do appreciate it a lot. Grid Engine supports parallel jobs via parallel environments (PE) that can be associated with cluster queues. New parallel environment is created using the qconf -ap
$ qconf -sp simple_pe pe_name simple_pe slots 4 user_lists NONE xuser_lists NONE start_proc_args /bin/true stop_proc_args /bin/true allocation_rule $round_robin control_slaves FALSE job_is_first_task FALSE urgency_slots min
In the above example, “slots” defines number of parallel tasks that can be run concurrently. The “user_lists” (“xuser_lists”) parameter should be a comma-separated list of user names that are allowed (denied) use of the given PE. If “user_lists” is set to NONE, any user that is not explicitly disallowed via the “xuser_lists” parameter. The “start_proc_args” and “stop_proc_args” represent command line of startup and shutdown procedures for the parallel environment. These commands are usually scripts customized for a specific parallel library intended for a given PE. They get executed for each parallel job, and are used, for example, start any necessary daemons that enable parallel job execution. The standard output (error) of these commands are redirected into
#!/bin/sh
#$ -S /bin/sh
slaveCnt=0
while read host slots q procs; do
slotCnt=0
while [ $slotCnt -lt $slots ]; do
slotCnt=`expr $slotCnt + 1`
slaveCnt=`expr $slaveCnt + 1`
ssh $host "/bin/hostname; sleep 10" > /tmp/slave.$slaveCnt.out 2>&1 &
done
done < $PE_HOSTFILE
while [ $slaveCnt -gt 0 ]; do
wait
slaveCnt=`expr $slaveCnt - 1`
done
echo "All done!"
After saving this script as "master.sh" and submitting your job using something like "qsub -pe simple_pe 3 master.sh" (where 3 is the number of parallel slots requested), you should be able to see your "slave" tasks running on the allocated machines. Note, however, that you must have password-less ssh access to the designated parallel compute hosts in order for the above script to work.
منبع : http://gridgurus.typepad.com
The Role of Open Source in Grid Computing
Grid Guru Ian Foster has a great piece in International Science Grid This Week. He talks about the significance of choosing open source licenses in the history of Globus, leading to a field dominated by open source software.
منبع : http://gridgurus.typepad.com
The MapReduce Panacea Myth?
Everywhere I go I read about how the MapReduce algorithm will and continues to change the world with its pure simplicity… Parallel programming is hard but MapReduce makes it easy... MapReduce: ridiculously easy distribute programming… Perhaps one day programming tools and languages will catch up with our processing capability but until then, MapReduce will allow us all to process very large datasets on massively parallel systems without having to bother with complicated interprocess communication using MPI.
I am a skeptic, which is not to say I have anything against a generalized framework for distributing data to a large number of processors. Nor does it imply that I enjoy MPI and its coherence arising from cacophonous chatter (if all goes well). I just don’t think MapReduce is particularly "simple". The key promoters of this algorithm such as Yahoo and Google have serious-experts MapReducing their particular problem sets and thus they make it look easy. You and your colleagues need to understand your data in some detail as well. I can think of a number of examples of why this is so.
First, let’s say that you are tasked with processing thousands of channels of continuously recorded broadband data from a VLBI based radio-telescope (or any other processing using beam-forming techniques for that matter). You cannot simply chop the data into nice time-based sections and send it off to be processed. Any signal processing that must be done to the data will produce terrible edge effects at each of the abrupt boundaries. Your file-splits must do something to avoid this behavior such as padding additional data on either side of the cut. This in turn will complicate the append phase after the processing is done. Thus you need to properly remove the padded data – if the samples do not align in a coherent way, then you will introduce a spike filled with energy into your result.
Alternatively, you might have been tasked with solving a large system of linear equations. For example say you are asked to produce a regional seismic tomography map with a resolution down to a few hundred meters using thousands of earthquakes each with tens of observations. You could easily produce a sparse system of equations that creates a matrix with something on the order of one million columns and several tens if not hundreds of thousands of rows. Distributed algorithms for solving such a system are well known but require our cranky friend MPI. However we can map this problem to several independent calculations as long as we are careful no to bias the input data as in the previous example. I will not bore you with the possibilities but suffice it to say that researchers have been producing tomographic maps for many years by carefully selecting the data and model calculated at any one time.
I know what many of you are thinking – I’ve read it before: MapReduce is meant for "non-scientific”"problems. But is a sophisticated search-engine any different? What makes it any less "scientific" than the examples I provided? Consider a search-engine that maintains several (n) different document indexes distributed throughout the cloud. A user then issues a query which is mapped to n servers. Let’s assume for the sake of time, each node returns its top m results to the reduce phase. These m results are then sorted and returned to the user. The assumption here is that there is no bias in the distribution of indexed documents relevant to a user’s query. Perhaps one or more documents beyond the first m found in one particular index are far more relevant than the other (n+1) * m results from the other indexes. But the user will never know. Should the search engine return every single result to the reduce phase at the expense of response time? Is there a way to distribute documents to the individual indexes to avoid well-known (but not all) biases? I suggest that these questions are the sorts of things that give one search-engine an edge over another. Approaches to these sorts of issues might well be publishable in referred journals. In other words, it sounds scientific to me.
I hope that by now you can see why I say that using MapReduce is only simple if you know how to work with (map) your data (especially if it is wonderfully-wacky). There is an inherent risk of bias in any map reduce algorithm. Sadly this implies that processing data in parallel is still hard no matter how good of a programmer you are nor how sophisticated your programming language is.
منبع : http://gridgurus.typepad.com
Open Evolution
Proprietary standards can bring success at first but cannot last. At least that is the conclusion we are forced to draw from two interesting articles in the 22 March issue of the Economist: Break down these walls and Everywhere but nowhere. I highly recommend that you read them particularly if you think that Ian’s Grid definition requiring open-standards is debatable.
The core lesson comes from the original big players in the nascent internet such as AOL, CompuServe, and Prodigy. These companies provided their users with electronic mail (not necessarily what we consider email today), chat rooms, discussion boards, and access to a wide-range of information. However these services were restricted to users of each particular service. You simply could not access information from one provider if you subscribed to another.
However, it was not long before products based upon open standards that provided these same services (and more) became more attractive to users simply because they allowed people to venture outside of the closed communities to which they subscribed. Once these users got out, they never turned back. The original content-providers became nothing more than access points to the web. Consequently these service providers quickly lost their luster and thus their valuation. Only AOL was able to (and still struggles to) survive, having redefined itself as a web-portal with paid advertising – just like the services that nearly killed it.
Today, the hottest products in the digital world are the social-networking sites like Facebook and MySpace as well as virtual worlds such as Second Life. Their popularity and usefulness to individuals has given them significant momentum in the marketplace as the “next big-thing”. Consequently these companies have been given enormous valuations despite having no business model beyond the fact that they have hordes of captive-users. While these products typically come with an API so that users can add useful and interesting features, it is no substitute for true-operational freedom. People want to interact others without having to switch systems or maintain two distinct profiles.
How long will it be before social-networking products appear that are not only based upon open-standards but also offering better features and more accessibility? You can bet that it will be soon given the amount of potential money involved. Then the reckoning will come and these companies, once flying high, will either be forced to adapt or perish.
What does this teach us about computing beyond the desktop, howsoever you wish to define it, be that a Grid, Cloud, or whatnot? Personally, I think it is clear: we must develop to open-standards or perish. I cannot see how the Grid market is immune to pressures of interoperability and freedom of choice. To paraphrase the Economist, why stay within a closed community when you can roam outside its walled garden, into the wilds of open computing!!!
I hope to see you all at the Open Source Grid and Cluster Conference.
منبع : http://gridgurus.typepad.com
There's an Analyst Lurking in that Business
I recently read an editorial from Grid Today (GT) based upon conversations with Forrester’s Frank Gillett suggesting that interest in Grid computing is waning. I will not dispute the veracity of this claim; rather I will leave that to the people such as the HPC Today editorial staff who have access to the Forrester report. Irrespective of the actual level of interest that buyers have in the Grid, I was rather baffled by the reasons that Grid Today provided for the general "malaise".
The first reason that GT offers is that, "grid computing is, in general, beneficial to vertically specific applications." More specifically, they indicate that there are limited sets of applications that could benefit from grid computing. I am assuming that the set of applications that they are referring to are those which require high-performance parallel calculations as well as any algorithm that can use the Map-Reduce pattern to distribute the computational load across many servers.
So which classes of applications do not work well on the grid? Clearly Service Oriented Architectures (SOA) works well on the Grid. In fact the Globus Toolkit, a popular software toolkit for building grids, uses SOA at its core.
Yet I believe that any n-tier application run on a Grid has many advantages. For example, imagine a web-based application with a supporting relational database that is required to scale under significant user loads including the number of connections but also the complexity of the requested services. Also imagine that clusters of users in different regions will use this application.
First of all, it would be nice for us to provide the data-services of this application using a SOA. Doing so allows us to expose the data through a single access-layer. Thus any program can access the data using the same business rules without tying it to a single-application interface. Secondly, if users require any complex reports or other heavy-duty calculations, a single web-server might easily be overwhelmed and thus forced out of the rotation until the process completes. A better solution would be for the web-server to farm these sorts of operations out to the Grid – maybe even using a Map-Reduce pattern. Furthermore adding Grid capacity is an easy way to handle high-peak loads of the application. These resources could be used by other projects during the off-peak periods. Lastly, the grid could coordinate resources that are proximate to the regional user-clusters and thus reduce communication latency for any data that needs to be exchanged without having to keep copies of the web or data-infrastructure throughout the enterprise.
If there are advantages to running your n-tier applications on the grid, it is not much of a stretch architecturally to extend that to other classes of application. I could not imagine implementing a SaaS (Software as a Service) application on anything but a grid. Having said that, I don’t believe that an application needs to be complicated to run better on a Grid. Rather, I think any application that users rely on is a good candidate.
Many "desktop" applications not only can be run on the grid but also are more appropriate to do so. Data centric applications are the prime candidates that come to mind. First of all, keeping results on your desktop all but kills collaboration between users because it is likely on an high-latency low-availability network, may be a separate security-domain and thus inaccessible to many users, and could be shutdown at any time. In addition, if an application reads and/or writes significant amounts of important data, it is best to keep it in the data-center on reliable and, more-importantly, regularly backed-up storage. Of course, the application could write across the typical high-latency low-availability desktop network into the datacenter, but that is fraught with problems. Personally I believe that perhaps the most significant source of user frustration is "network drives" – but I digress. If an application’s calculations take any significant resources, the user’s desktop quickly becomes a bottleneck. Even if the user’s machine is beefy enough to handle running a job while still allowing access to email, they are still hardware limited. In particular, if the application can be submitted in batch to the grid, the user could literally submit dozens if not hundreds of individual calculations and get the results in a fraction of the time it would take on their desktop. Lastly, running jobs at the datacenter frees users from using a single desktop. Rather, they can manage their computing from any location, which provides them significantly more freedom.
All of this brings me to GT’s second key assertion: that the term Grid has been, "bandied about so much that no one knows what it means or what business benefits they might derive from it." This is indeed the core challenge. My experience is that very few business proponents specify software-architectures. Generally they could care less whether a salesperson is pushing SOA, Grid, Cloud, SaaS, or whatnot. These are the concerns of people who support business-lines: CTOs, IT support-managers, etc.
Chances are you are not dealing with these sorts of technical folks when you are drafting a proposal. Rather, you are likely speaking with a business-analyst. The ones I know are not easily charmed by buzzwords (even if their bosses or peers are). They are more than aware that terms mean different things to different vendors and their staff.
Frankly they don’t care about your pet technology. Instead, they have a set of goals and a given budget. They are measured on how well the project met the user’s needs, how under-budget it came in, and how much time it took. If any one proposal that they have happens to align with other business initiatives of which they are aware, then they will consider the advantages as well as the costs of implementing it. We all know that individual business groups tend to go their own ways, particularly in large companies. We are not going to corral them with the "Grid".
Yet there is plenty of hope for us. We Grid proponents should focus on providing small group-level systems that are quickly setup, scale easily, and meet the customer’s defined business goals. These implementations do not need to fall under the traditional association that Grid has with high-performance computing (HPC): HPC is not often amongst the business goals. However if the group Grid is built using open-standards, has a resource manager, and allows for the provisioning of global management systems (e.g. authentication domains), it is easy for the technical types to incorporate this small-Grid into an enterprise-wide effort. This is how we can sell the Grid.
منبع : http://gridgurus.typepad.com
OpenNEbula and VWS
Few days ago authors of the GridWay Metascheduler released Technology Preview of their OpenNEbula Virtual Infrastructure Engine (ONE), which enables deployment and management of virtual machines on a pool of physical resources. The software is very similar to the Globus Virtual Workspace Service (VWS), both in architecture and functionality. Both systems provide new service layer on top of the existing virtualization platforms (currently they support only the Xen hypervisor). This layer extends functionality of the underlying Virtual Machine Monitors (VMMs) from a single machine to a VM provisioning cluster. Both ONE Engine and VWS utilize passwordless SSH access to manage pool of nodes running VMMs, and allow system administrators to deploy new VMs, to start/shutdown and suspend/resume already deployed VMs, as well as to migrate VMs from one physical host to another. The most notable difference between ONE and VWS is that VWS is built on top of the GT infrastructure, and runs within the GT java container. This allows, for example, using RFT for stage-in/stage-out requests to be sent along with the workspace creation requests. On the other hand, the ONE Engine is a standalone service and its installation requirements include only a few software packages that are already present in most linux distributions.
منبع : http://gridgurus.typepad.com
Ten More Reasons to go to Oakland
Rich Wellner came up with four reasons to attend the Open Source Grid and Cluster Conference, to be held in Oakland May 12-16. I outdid him and came up with 10:
1) Globus program is fantastic, including tutorials, advanced technical presentations, contributed talks, and community events on every aspect of Globus.
2) Gobs of other material on Sun Grid Engine and Rocks, and other open source grid and cluster software.
3) Gathering: A great opportunity to meet colleagues, peers, collaborators from the grid and cluster community. The only grid meeting in the US the rest of this year--the next two OGFs are in Spain (June) and Singapore (September).
4) GT4.2: You'll get to learn about the exciting new features in Globus Toolkit 4.2. New execution, data, security, information, virtualization, and core services.
5) Gratfication (immediate) as you get to provide your input on future directions for Globus, Sun Grid Engine, Rocks, and other open source systems--and maybe sign up to contribute to those developments.
6) Grid solutions: You'll get to meet the people using Globus to build enterprise grid solutions in projects like caBIG, TeraGrid, Earth System Grid, MEDICUS, and LIGO, and learn about solution tools like Introduce, MPI-G, Swift, Taverna, and UniCluster.
7) Gurus: You get to grill the Globus gurus--or, if you prefer, show off your own Globus guru status.
8) Great price: $490 registration is substantially cheaper than OGF or HPDC, for example, and the hotel rate is reasonable ($149).
9) Gorgeous location: Oakland is easy to get to -- SFO (with easy BART train ride), Oakland, and San Jose airports also nearby. Just a 10 minute train ride to download San Francisco. A lovely time to be in the Bay Area.
10) Gorilla and guerilla free: None of the corporate marketing talks that diluted the last GridWorld conference--apart from two sponsor talks, this is pure tech, and highly useful tech at that!
منبع : http://gridgurus.typepad.com
A Grid OS?
I have recently been working on a test plan for a framework designed to deliver applications to grid users. The framework is useful for the specific environment in which the customer operates. However it has led me to imagine something more generic that anybody who manages a Grid intended for use by a diverse community would find useful.
You need to have a solid software infrastructure consisting of compilers, libraries, middleware, languages, and services. Your customers want to be able to run the applications that suit their goals best with as little fuss as possible. These include off-the-shelf, commercial customizations, open-source, freeware, supported in-house, and individually built software packages.
While there may be few interoperability issues within a small group or company, you can bet that not all programs will play well with others. Some applications will require very specific libraries and middleware while others will prove to be quite flexible. Some applications require supporting software for 64-bit architectures while others need 32-bit. Other software has different feature-sets on different hardware (e.g. SPARC versus x86) as well as software (e.g. Linux versus IRIX) systems. Still other applications, particularly those that are on long development cycles, tend to use older feature sets whose behavior may have changed or been eliminated from subsequent package releases. Meanwhile your in-house developers might be working on the bleeding-edge and therefore use software that is too unstable for the general user community. Face it: very few software developers expect their products to co-exist with others.
This is a big challenge for anybody who is expected to create a shared-computing environment for a big user community. Typically system administrators will create an operating-system image based upon anticipated usage patterns, security, stability, feature-sets, and availability. They will have specific builds for their web-farm, mail-servers, storage-nodes, and (most importantly) for our Grid computation nodes. They would also like to be proactive and keep their systems up to the latest security and bug-fix patch levels. In addition, they are going to try to provide the best product they can; therefore they would like to provide the most feature-rich infrastructure with which they feel-comfortable. However, and most importantly, they will use a package manager to maintain software releases on their machines. Why would any system manager want to reinvent the wheel when it comes to building software when the vendors will do it for them?
This last practice has a significant impact on the software you will find on the Grid. If the hardware vendor has a build for the software you use, chances are that is what you will get. These package managers tend to keep only one version of a particular software package on a system at a time. Consequently if a newer version of a package is desired, the older one is removed. Even if they tried to make multiple packages coexist, files would be overwritten. There are a few "compat" versions but these are exceptions.
Clearly, when your mandate is to provide a shared computing environment that has a significant number of processing nodes as well as users, you will have to provide a more substantive infrastructure. At this point you could either build specialized virtual machines for each operating environment or you can create a shared infrastructure that any image can use. Utility-computing players like Amazon have you create your own machine image (AMI) but I think it is unreasonable to expect application users to have the skills to create a proper operating environment.
The second option, creating a shared infrastructure that any image can use could be considered a grid operating system from scratch vis-à-vis Linux from scratch. This type of framework would force us to place our software into a categorized structure capable of differentiating operating systems, hardware architectures, and application versions. This infrastructure should not replace the standard installs for the operating system in order to avoid conflicts – providing application support for a grid is orthogonal to managing a compute node.
All of this needs to work without overtaxing your customers (i.e. application users). The typical user doesn’t care which operating environment they are provided as long as their software runs. Rather they would prefer to be able to call their application as if it were the only version using the only installed system libraries and middleware on the only supported compute node configuration. Basically if a user wishes to use an application, they simply want to call it by name: for example python and perhaps python-2.3.7 or python-2.4.5 should they require a particular version.
A big component of your effort in creating the proposed framework is providing the correct versions of libraries and middleware to your customers’ frontline applications; this is a task that demands specialized configuration scripts whose job is to set-up the operating environment to match the user request and the operating environment. There are a few tools out there that are quite capable of accomplishing something like this. However there is nothing that I am aware of whose goal it is to specifically deliver applications on a grid. Instead this class of tools provides far more flexibility than what is necessary, let alone wanted.
Ultimately I think that the best thing for the industry would be to establish a standard Grid directory structure for placing software in shared environments (e.g. /
منبع : http://gridgurus.typepad.com
عالم پير، گريد جوان - Grid Computing و بزرگترين ماشينهاي علمي ساخت بشر
نويسندگان: Fabrizio Gagliardi و Francois Grey ؛ ترجمه: سيدمصطفي ناطقالاسلام
ماهنامه شبکه - شهريور ۱۳۸۶ شماره 79
اشاره :
اگر همه چيز مطابق برنامه پيش برود، سال آينده بزرگترين ماشين علمياي كه تاكنون ساخته شده است، در مجتمع زيرزميني پرپيچ و خمي در سوئيس، نزديك ژنو، به بهرهبرداري خواهد رسيد. تصادمگر بزرگ هادرون (LHC) كه در عمق بيش از صد متري زير زمين قرار دارد، دو باريكه پروتون را در جهتهاي مخالف هم در يك تونل دايرهاي 27 كيلومتري شتاب خواهد داد. اين دو باريكه، در حالي كه تقريباً به سرعت نور رسيدهاند، به صورت متقابل (شاخ به شاخ) با هم برخورد ميكنند و رگباري از بقاياي زيراتمي را توليد ميكنند كه دانشپيشگان انتظار دارند ذراتي مرموز را كه قبلاً هرگز مشاهده نشدهاند، در ميان آنها بيابند. اين امر ميتواند منجر به تغيير در درك بنيادي ما از جهان گردد. دستكم، اميد است كه چنين شود. پژوهشگران سازمان تحقيقات هستهاي اروپا (سرن)، جايي كه LHC به بهرهبرداري خواهد رسيد، ميدانند كه يافتن ذرات مادي گريزاني كه آنها در جستوجويش هستند، كار بسيار دشواري خواهد بود. براي يافتن اين ذرات، پژوهشگران بايد تودههاي مهيبي از دادههاي مربوط به برخوردها را غربال نمايند: انتظار ميرود فوران دادهها در LHC به طور متوسط، سالانه به پانزده ميليون گيگابايت برسد؛ اين مقدار بيشتر از ميزان دادهاي است كه براي پر كردن شش ديويدي استاندارد در دقيقه لازم است. به اين ترتيب مرتب كردن و تحليل نمودن اين كوه دادهها كاري است فراتر از توان هر ابركامپيوتري در جهان. پس در همان حال كه تيم LHC براي تكميل نمودن ماشين غولپيكر زيرزميني در تكاپو است، روي سطح زمين گروه ديگري از فيزيكپيشگان و متخصصان علوم كامپيوتر در حال حل نمودن مسئلهاي مستقل هستند: فراهم آوردن زيرساختي محاسباتي كه از پس سيلاب دادههاي LHC برآيد. راهحلي كه آنان يافتهاند مجموعهاي پهناور از كامپيوترهاي قدرتمند كه حدوداً در دويست مركز پژوهشي در سراسر دنيا گستردهاند و به گونهاي مرتبط و پيكربندي شدهاند كه همچون يك سيستم واحد پردازش موازي كار كنند. اين نوع زيرساخت يك گريد پردازشي (computing grid) خوانده ميشود.
كارگاه آموزشي دادهكاوي و هشتمين همايش ديفرانسيل، سيستمهاي ديناميكي و كاربردهاي آن خرداد و تيرماه در دانشگاه صنعتي اصفهان برگزار ميشود.
به گزارش روز چهارشنبه روابط عمومي دانشگاه صنعتي اصفهان، دكتر"حميدرضا ظهوري" دبير اين همايش گفت: اين نشست با هدف تبادل نظر علمي محققان علوم رياضي و مهندسي هر دو سال يك بار برگزار و پيش بيني ميشود حدود ۲۰۰محقق داخلي و خارجي در آن شركت كنند.
وي افزود: در برگزاري اين همايش دانشگاههاي صنعتي اصفهان، شريف و انجمن رياضي مشاركت دارند و مجموعه مقالات ارائه شده در آن به عنوان ويژهنامه در بولتن انجمن رياضي ايران چاپ ميشود.
وي تصريح كرد:علاقهمندان به شركت در اين نشست ميتوانند مقالات خود را تا ۱۱خرداد ماه به آدرس اينترنتي http://deds8.math.iut.ac.irارسال كنند.
همچنين"محمد روزبه"دبير كارگاه آموزشي دادهكاوي نيز گفت: اين كارگاه با همكاريمركز كارآفريني دانشگاه صنعتياصفهان و شهرك علمي و تحقيقاتي اصفهان از ۳۱ارديبهشت تا دوم خرداد برگزار ميشود.
وي افزود: دراين كارگاه، " غلامرضا نخعيزاده " استاد دانشگاه" كالسروهه" آلمان كه مدير سابق دپارتمان دادهكاوي شركت مرسدس بنز بوده، طي سه روز تجربيات علمي خود را در اختيار شركتكنندگان در اين كارگاه قرار ميدهد.
وي تصريح كرد: علاقهمندان بهشركت دراين كارگاه تا ۲۰ارديبهشت ميتوانند درخواست خود را به پايگاه اينترنتي www.ep-dm.comارائه كنند.
منبع : irna.ir
معرفی موسسه پژوهشی داده پردازان گیتا
سایت موسسه : http://www.gitadatamining.com
موسسه پژوهشی داده پردازان گیتا در سال 1383 بعنوان اولین موسسه پژوهشی تخصصی در زمینه داده کاوی در ایران توسط آقای دکتر جمال شهرابی عضو هیات علمی دانشکده مهندسی صنایع دانشگاه صنعتی امیرکبیرو با همکاری جمعی از فارغ التحصیلان مهندسی صنایع دانشگاه، با هدف بسط، گسترش و بکارگیری دانش نوین داده کاوی در کشور تاسیس گردید.
برگزاری سمینارها و دوره های آموزشی، کنفرانسهای ملی و بین المللی، اجرای پروژه های پژوهشی داده کاوی در موسسات، وزارتخانه ها و سازمان های کشور و چاپ کتب مرتبط از جمله فعالیتهای موسسه پژوهشی داده پردازان گیتا می باشد.
موسسه پژوهشی داده پردازان گیتا با همکاری موسسات و دانشگاههای معتبر خارج از کشور تلاش دارد که در جهت نشر و گسترش تکنولوژیهای نوین در کشور گام بردارد. برخی از محورهای تخصصی پژوهشی موسسه عبارتند از:
- داده کاوی Data Mining
- داده کاوی مکان محور در سیستمهای اطلاعات جغرافیایی Spatial Data Mining
- طراحی سیستمهای مکان یابی و مسیریابی Location and Routing Analysis Systems
- تحقیقات بازار Market Research
- آنالیز های چند متغیره داده Multivariate Data Analysis
از جمله دستاوردهای موسسه پژوهشی داده پردازان گیتا انجام چندین پروژه موفق در کشور، انتشار چندین عنوان کتاب و انتشار چندین مقاله علمی در نشریات و کنفرانسهای معتبر علمی جهان می باشد.
معرفی و طرح موضوع داده کاوی در کشور و ابتکار برگزاری کنفرانس داده کاوی ایران و برگزاری کارگاه های آموزشی تخصصی داده کاوی که برای اولین بار بصورت چند رسانه ای و بصورت کاملا حرفه ای برگزار میگردد از جمله دستاورد های اخیر موسسه پژوهشی داده پردازان گیتا میباشد.
دانشمندان با استفاده از نازكترين ماده جهان، كوچكترين ترانزيستور دنيا را با يك اتم ضخامت و ۱۰اتم پهنا، ساختند.
به گزارش ساينس ديلي، دكتر كوشتيا نووسلوف و پروفسور آندري گيم از دانشكده فيزيك و ستاره شناسي داتشگاه منچستر نشان دادند ميتوان اين ماده جديد را كه گرافن نام دارد براي ساخت مدارهاي الكترونيكي كوچكي برش داد و ترانزيستورهايي ساخت كه ابعادي بزرگتر از يك مولكول ندارند.
محققان ميگويند هرچه اندازه يك ترانزيستور كوچكتر باشد عملكرد آنها بهتر است.
در دهههاي اخير توليدكنندگان، اجزاي بيشتر و بيشتري را به مدارهاي مجتمع افزوده اند. در نتيجه تعداد ترانزيستورها و توان اين مدارها تقريبا هر دو سال، دو برابر شده است كه اين روند به عنوان قانون مور شناخته شده است.
بر اساس نقشه راه صنعت نيمه هادي، اكنون سرعت افزايش حجم بطور قابل توجهي در حال كاهش است و متخصصان الكترونيك براي كوچكسازي بيشتر وسايل الكترونيكي بايد مهمترين چالش خود طي ۱۰تا ۲۰سال آينده روبرو شوند.
ثبات ناكافي مواد هنگامي كه ابعاد آنها به كمتر از ۱۰نانومتر برسد مشكل اصلي است. در اين مقايس فضايي تمام نيمه هاديها از جمله سيليكون اكسيده و تجزيه ميشوند و بطور غير قابل كنترلي مانند قطرات آب بر روي يك سطح داغ، در امتداد سطوح به حركت درمي آيند.
گيم و همكارانش چهار سال پيش گرافن را كشف كردند. گرافن نخستين ماده به ضخامت تك اتم است كه ميتوان آن را به صورت سطحي از اتمهاي تخليه شده از گرافيت تلقي كرد. گرافن در علوم مواد و فيزيك ، به سرعت به مهمترين موضوع تبديل شده است.
اكنون تيم تحقيقاتي دانشگاه منچستر امكان ساخت ترانزيستورهاي در مقياس نانويي با استفاده از يك كريستال گرافن را به اثبات رسانده اند.
گرافن برخلاف تمامي مواد شناخته شده حتي وقتي كه ابزارهاي يك نانو متر ي از آن ساخته ميشود بسيار باثبات و هادي باقي ميماند.
ترانزيستورهاي گرافني در اندازههاي كمتر از ۱۰نانومتر مزايا و عملكرد مناسبي از خود نشان ميدهند.
نووسلوف ميگويد،پيش از اين محققان سعي كرده بودند از مولكولهاي بزرگ به عنوان ترانزيستورهاي واحد براي ساخت نوع جديدي مدارهاي الكترونيكي استفاده كنند. اين كار مانند بهرهگيري از شيمي در مهندسي رايانه است، گيم افزود هنوز براي وعده ساخت ابررايانههاي گرافني خيلي زود است. ما دراين كار تحقيقاتي براي ساخت چنين ترانزيستورهاي كوچكي به شانس تكيه كرديم.
وي اظهار داشت متاسفانه هيچ فناوري وجود ندارد كه بتوان با استفاده از آن مواد را با اندازه نانومتري دقيقي برش داد. اما اين دقيقا همان چالشي است كه تمام متخصصان الكترونيك بايد با آن روبه رو شوند.
اين دانشمند تاكيد كرد دستكم اكنون مادهاي داريم كه ميتوان با استفاده از آن با اين چالش مواجه شد.
باب وسترولت استاد دانشگاه هاروارد گفت گرافن ماده جديد جالبي با ويژگي هاي غير عادي است كه براي نانوالكترونيك نويد بخش محسوب ميشود.
منبع : http://www1.irna.ir/fa/news/view/menu-152/8701319848151136.htm
(thread)و سیستمهای multitasking
در تکنیک چندنخی (multitasking) یک فرایند (process) که برنامهای در حال اجراست , میتواند به بخشها یا نخهایی (بندهایی ) تقسیم شود که میتوانند به صورت همزمان اجراء شوند.
برنامههایی که چند وظیفه مستقل از هم را انجام میدهند میتوانند به صورت چن نخی نوشته شوند. گاهی اوقات به سیستمهای multithreading سیستمهای چند تکلیفی یا چند وظیفه ای (multitasking)هم گفته میشود.
فرآیند (process)یا پردازش اساس یک برنامه در حال اجراست که منابعی از سیستم به آن تخصیص داده شده است (شامل رجیسترها,حافظه,فایلها و دستگاهها).فرآیند میتواند مجموعهای از یک یا چند نخ باشد. به نخ, رشته یا بند هم گفته میشود . کلیه اطلاعات مربوط به هر پروسس , در یکی از جداول سیستم عامل به نام جداول Process Control Block=PCB ذخیره میشود. این جدول یک آرایه یا لیست پیوندی از ساختارهاست که هر عضو آن مربوط به یکی از پروسسهاست که در حال حاضر موجودیت دارد.
اطلاعات موجود در PCB عبارتند از : حالت جاری پردازش ,شماره شناسایی پردازش , اولیت پردازش , نشانی حافظه پردازش , نشانی محل برنامه پردازش بر روی دیسک , نشانی سایر منابع پردازش , محلی برای حفظ ثباتها .
منبع :شبه رشد
Cluster, and so Grid site, administrators have to deal with the following requirements when configuring and scaling their infrastructure:
In order to overcome these challenges, we propose a new virtualization layer between the service and the physical infrastructure layers, which seamless integrates with existing Grid and cluster middleware stacks. The new virtualization layer extends the benefits of VMMs (Virtual Machine Monitors) from a single physical resource to a cluster of resources, decoupling a server not only from the physical infrastructure but also from the physical location. In the particular case of computing clusters, this new layer supports the dynamic execution of computing services, working nodes, from different computer clusters on a single physical cluster.
OpenNebula is the name of a new open-source technology that transforms a physical infrastructure into a virtual infrastructure by dynamically overlaying VMs over physical resources. So computing services, such as working nodes managed by existing LRMs (Local Resource Managers) like SGE, Condor, OpenPBS..., could be executed on top of the virtual infrastructure; so allowing a physical cluster to dynamically execute multiple virtual clusters.
The separation of resource provisioning, managed by OpenNebula, from job execution management, managed by existing LRMs, provides the following benefits:
Consequently, this approach provides the flexibility required to allow Grid sites to execute on-demand VO-specific working nodes and to isolate and partition the physical resources. Additionally, the architecture offers other benefits to the administrator of the cluster, such as high availability, support for planned maintenance and changing capacity availability, performance partitioning, protection against malicious use of resources...
The idea of a virtual infrastructure which dynamically manages the execution of VMs on physical resources is not new. There exist several VM Management proprietary solutions to simplify the use of virtualization, so providing the enterprise with the potential benefits this technology may offer. Examples of products for the centralized management of the life-cycle of a VM workload on a pool of physical resources are: Platform VM Orchestrator, IBM Virtualization Manager, Novell ZENworks, VMware Virtual Center, and HP VMManager.
The OpenNebula Virtual Infrastructure Engine differentiates from those VM management systems in its highly modular and open architecture to meet the requirements of cluster administrators. The OpenNebula Engine provides a command line interface for monitoring and controlling VMs and physical resources quite similar to that provided by well-known LRMs. Such interface allows its integration with third-party tools, such as LRMs, service adapters, VM image managers...; to provide a complete solution for the deployment of flexible and efficient computing clusters. The service layer decoupling from the infrastructure layer allows an straightforward extension of the previous idea to any kind of service. In this way any physical infrastructure can be transformed into a very effective provisioning platform.
A Technology Preview of OpenNebula is available for download under the terms of the Apache License, version 2.0.
Ignacio Martín Llorente
Reprinted from blog.dsa-research.org
منبع : http://gridgurus.typepad.com
My esteemed Grid Gurus moderator, Rich Wellner, asked "what is the most creative use for grid technology that you've ever seen?" This is a difficult question to answer, but I will attempt to do so anyway.
I choose the work of George Karniadakis, Suchuan Dong, Nick Karonis, and their colleagues on modeling blood flow in the human body. Why I like it is the wacky (sorry, wonderful) way in which they mapped this apparently highly tightly coupled problem onto the distributed sites of the NSF TeraGrid. Quoting one of their papers:
Motivated by a grand-challenge problem in biomechanics, we are striving to simulate blood flow in the entire human arterial tree. The problem originates from the widely accepted causal relationship between blood flow and the formation of arterial disease such as atherosclerotic plaques. These disease conditions preferentially develop in separated and recirculating flow regions such as arterial branches and bifurcations. Modeling these types of interactions requires significant compute resources to calculate the three-dimensional unsteady fluid dynamics in the sites of interest. Waveform coupling between the bifurcations, however, can be reasonably modeled by a reduced set of one-dimensional
equations that capture the cross-sectional area and sectional velocity properties. One can therefore simulate the entire arterial tree using a hybrid approach based on a reduced set of one-dimensional equations for the overall system and detailed 3D Navier-Stokes equations at arterial branches and bifurcations.
In other words, they mapped different parts of the human body (chest, legs, arms, head, and their arterial branches) to different TeraGrid sites, linking them by a simple, non-communication intensive 1-D problem.
The tools used to make this happen were MPICH-G2 (recently renamed as MPIG) and of course Globus.
منبع : http://gridgurus.typepad.com
The emergence of cloud computing as a resource on the grid has led to a huge resurgence in interest in utility computing. Looking at the history of utility computing allows us to identify three canonical interaction models that also apply to cloud computing.
Metascheduling
Initial cloud offerings like Amazon Elastic Compute Cloud created the nomenclature around clouds. Going back before the term "cloud" was coined we see a similar offering from Sun with their utility computing offering. In both cases users submit work to the service and eventually get results returned. How the request gets prioritized, provisioned and executed is at the discretion of the service provider. In many ways this is similar to how a typical cluster works. A user selects a cluster, submits a job and waits for a response. What node is used to execute his request is largely out of his control. While acknowledging there are substantial difference between a cluster and a cloud, another similarity reveals itself when thinking about how users interact with compute resources in companies that operate multiple clusters.
As companies began adding additional clusters, users quickly demanded a facility to submit their jobs to a high level service that would manage the interactions with all the clusters that were available. Most users didn't want to have to themselves use multiple monitoring tools to access multiple clusters and use the information gathered to make a decision about where to submit their job. What they wanted was a single interface to submit jobs to and a service that would make policy based decisions about which cluster to ultimately submit the request.
The situation today is similar. Multiple cloud and utility computing vendors exist and users don't want to spend their time gathering information about the state of each in order to decide where to submit their jobs. Further, administrators and managers need to be able to enforce policy. There are several reasons for requiring this behavior, but probably the easiest to explain is that there are costs associated with resource usage at the cloud vendors and organizations require control over how that money is spent.
The answer to all these needs is to place a metascheduler between the users and the various resources. Users can then use a single interface for all their jobs regardless of where they are ultimately going to be executed.
[A metascheduler] enables large-scale, reliable and efficient sharing of computing resources (clusters, computing farms, servers, supercomputers…), managed by different LRM (Local Resource Management) systems, such as PBS, SGE, LSF, Condor…, within a single organization (enterprise grid) or scattered across several administrative domains (partner or supply-chain grid). -- GridWay
Virtual machines
Clouds are only as useful as the software running in them. Therefore, the next important interaction model is that between users and virtual machines.
Users often need very specific software stacks. This includes the application they are running, support libraries and, in some instances, specific versions of operating systems. Analysts are saying that there are now at least 35 companies addressing the needs of users in managing these interactions. This includes software to implement the enactment layer, manage images, policy engines, user portals and analytics functions.
One of the questions yet to be answered in the cloud community is how to allow users to make use of several clouds on a day to day basis. As this market continues to mature, look for many of the same challenges (e.g. security, common APIs, WAN latencies) that the grid community has been tackling for over a decade to become increasingly important to cloud users.
Application virtualization
In the context of clouds, application virtualization gains significant power by being able to add or remove instances of applications on demand. This is currently being done in the context of data center management using proprietary tools. Clouds present a cool new opportunity to do the balancing act on a regional basis. As more clouds are built and standard interfaces made available, users will be able to load balance to multiple clouds operating in different countries or cities as demand grows and shrinks.
These three models represent established, powerful interaction modes that are being used in production in a variety of settings today. It will be interesting over the next year to see which cloud operators adopt which models and how many lessons they take from existing non-cloud implementation versus trying to reinvent the wheel in a new way.
منبع : http://gridgurus.typepad.com
The Grid Engine project has announced a new maintenance release (version 6.1 Update 4) of its software. This release fixes some 50+ issues found in earlier versions. In particular, couple of problems causing qmaster crashes have been resolved, and so were several dbwriter and accounting issues. More specifically, if you were wondering why your array job task usage is missing from the accounting file, you should consider installing this release. The new version of the software is available for download here. The grid.org team has just declared UniCluster 3.2 to be stable.
In particular, being able to install over an existing Grid Engine installation is super cool. This is a feature that I've been excited about for a long time as it brings globus, ganglia and the UniCluster monitoring application to the existing 10,000 or so Grid Engine clusters.
منبع : http://gridgurus.typepad.com
MPI vs. Compiler
Marlborough, MA, ? April 01, 2008 ? Scali, the leader in higher performance computing software, today announced new benchmark results provided by Scali using the SPEC MPI2007 benchmark suite on the newly released Scali MPI Connect version 5.6.1. As of today?s release, Scali cements its leadership and has the highest SPECmpiM_base2007 score for all systems ranging from 32 to 128 cores. Further, as a courtesy to the industry, Scali has submitted results using different compilers, enabling studies of which cluster components truly provide differential performance benefits. For a 32-node cluster system using 128 cores, the results show the compiler difference to be a modest 6 percent. However, on similarly equipped systems, these new results show that Scali MPI Connect extracts 18 percent more performance than HP-MPI (1).
?It is our top priority to deliver the best performing MPI in the industry and the newly submitted results underscore that commitment. Out of the 13 applications which constitute the SPEC MPI2007 medium suite running on 32 nodes and 128 cores, three of the applications performed within +/- 2 percent as compared to a similar system using HP-MPI. All the other 10 applications perform significant faster with Scali MPI Connect. For example the Quantum Chemistry application Socorro performs 21 percent faster with Scali MPI Connect. Additionally, the result for the POP2 benchmark, a climate modeling test using the Parallel Ocean Program (POP) showed a 336 percent performance advantage over the HP-MPI based system.?, said Hakon Bugge, CTO of Scali. ?We will continue our leadership role in providing the HPC community with the data they need to make important technology decisions. The choice is clear, over all; Scali MPI Connect is the best performing MPI in the market.?
SPEC MPI2007
SPEC MPI2007 is SPEC's benchmark suite for evaluating MPI-parallel, floating point, and compute intensive performance across a wide range of cluster and SMP hardware. MPI2007 continues the SPEC tradition of giving HPC users the most objective and representative benchmark suite for measuring the performance of SMP (shared memory multi-processor) systems. SPEC reviews and publishes submitted results on their website at: http://www.spec.org/mpi2007/results/ . SPEC? and the benchmark name SPEC MPI? are registered trademarks of the Standard Performance Evaluation Corporation. Competitive benchmark results stated above reflect results published on www.spec.org as of April 1, 2008.
About Scali and Scali MPI Connect
Founded in 1997, Scali is the leading developer of a fully integrated message passing interface (MPI) library that enables companies to take advantage of premier interconnect technologies to build high performance clusters. Scali MPI Connect is designed to enable applications to run at maximum performance through its unique, high performance, patent pending technology. Scali MPI Connect supports a wide range of customer environments while lowering the number of binaries required, and delivers superior application performance. Hundreds of companies, including Goodyear, Daimler AG, Lockheed Martin, US Army and Naval Air, Schlumberger and Shell benefit from using Scali?s MPI libraries. The company is headquartered in Marlborough, Massachusetts with research and development in Oslo, Norway and Nagpur, India. Visit http://www.scali.com for more information.
? 2008 Scali, Inc., All rights reserved. Scali and Scali MPI Connect are trademarks of Scali, Inc. All other service marks, trademarks, and registered trademarks are the property of their respective owners.
(1) The two systems labeled ? HP Proliant BL460c blade Cluster Platform 3000BL? and ? LS-1, Scali MPI Connect 5.6.1, Intel 9.1 compilers?, are both using Mellanox based Infiniband DDR HCAs, dual-core Intel Xeon 5160 processors and Intel 9.1 compilers. Using 32 nodes and 128 cores, the HP-MPI based system delivers a SPECmpiM(TM)_base2007 score of 11.9. The Scali MPI Connect based system delivers 14.0 using the same metric, i.e., 18 percent higher score. منبع : http://www.linuxhpc.org/stories.php?story=08/04/10/8378717
An Introduction To Distributed Intrusion Detection Systems
|
What is a dIDS? A distributed IDS (dIDS) consists of multiple Intrusion Detection Systems (IDS) over a large network, all of which communicate with each other, or with a central server that facilitates advanced network monitoring, incident analysis, and instant attack data. By having these co-operative agents distributed across a network, incident analysts, network operations, and security personnel are able to get a broader view of what is occurring on their network as a whole. A dIDS also allows a company to efficiently manage its incident analysis resources by centralizing its attack records and by giving the analyst a quick and easy way to spot new trends and patterns and to identify threats to the network across multiple network segments. This article will discuss distributed intrusion detection systems, including the general setup of a dIDS and a fictional case study to demonstrate the distributed analysis abilities. It will also try to give the reader some insight into the benefits of running a dIDS system, from both incident analyst and corporate views. Overview The Central Analysis Server The central analysis server is really the heart and soul of the operation. This server would ideally consist of a database and Web server. This allows the interactive querying of attack data for analysis as well as a useful Web interface to allow the corporate guys upstairs to see the current attack status of your network. It also allows analysts to perform pre-programmed queries, such as attack aggregation, statistics gathering, to identify attack patterns and to perform rudimentary incident analysis, all from a Web interface. The Co-operative Agent Network The co-operative agent network is one of the most important components of the dIDS. An agent is a piece of software that reports attack information to the central analysis server. The use of multiple agents across a network allows the incident analysis team a broader view of the network than can be achieved with single IDS systems. Ideally these agents will be located on separate network segments, and geographical locations (See diagram below.) The agents can also be distributed across multiple physical locations, allowing for a single incident analysis team to view attack data across multiple corporate locations.
Although any IDS could be used on the agent machines, it is highly suggested that Snort be used. It has been demonstrated, however, that any attack logging system can be incorporated into this agent network. This can range from router attack logs, to ipfw, firewalls, and even Windows personal firewall systems. Attack Aggregation Attack aggregation is another core part of the dIDS system. This part of the system is programming logic based on the central server. Aggregation simply refers to the method in which users group or order the information gathered from the agent network. One example of this would be to aggregate information according to attacker IP, putting all attacks from an attacking IP together with other attacks from the same IP. Another example is the aggregation of attack data according to destination (attacked) port, or even by date and time. Uses for aggregation will be explained later in this paper. Advantages of a dIDS Why a dIDS? Due to the greater view the agent allows the analyst to achieve, the dIDS offers the incident analyst many advantages over other single mode IDS systems. One of these advantages is the ability to detect attack patterns across an entire corporate network, with geographic locations separating segments by time zones or even continents. This could allow for the early detection of a well-planned and coordinated attack against the organization in question, which would allow the security people to ensure that targeted systems are secured and offending IPs are disallowed any access. Another proven advantage is to allow early detection of an Internet worm making its way through a corporate network. This information could then be used to identify and clean systems that have been infected by the worm, and prevent further spread of the worm into the network, therefore lowering any financial losses that would otherwise have been incurred. The second major advantage is that a single analysis team can now do what previously required several incident analysis teams due to physical distance. This obviates the need to pay for distinct incident analysis teams for each separate geographic location of the organization’s offices. Another issue that it addresses is attacks from within the corporations network by angry, upset, or bored employees. By tying the central analysis server in with the companies DHCP or RADIUS servers, the incident analysts can track down people launching attacks from within the company, and track what they have attempted to do, as well as provide evidence against the perpetrators. Incident Analysis With dIDS Incident analysis using the dIDS system is really what it is all about. This is where all the power, potential, flexibility, and strength of the system as a whole lies. It is the reason why the dIDS was first conceptualized, to allow for advanced analysis of attacks occurring over multiple network segments, and at an advanced level. Analysis Using Aggregation Aggregation is the main component used to facilitate this advanced method of analysis across a networks multiple segments. By aggregating similar or related data, the analyst is able to easily see how an attack progressed through the different stages: from active network reconnaissance, to the final attack. It is possible for the incident analyst to see what kind of time frame the attacker was working within and to correlate other attack attempts against the networks to determine if there were multiple co-operative attackers. The most common methods of aggregation are according to attacker IP, destination port, agent ID, date, time, protocol, or attack type.
By utilizing all of these aggregation methods, the analyst is given an unlimited number of different sets of data to correlate against other attacks, detect coordinated distributed attacks, attacks from within their own network, and to detect new exploits and vulnerabilities being deployed by the underground hacking community. The broad view given by the dIDS system also allows the analyst to ensure a minimum of false positives and false negatives by being able to see beyond a single network segment, into the network as a whole. For example, if the analyst saw that one out of five network segments got seven unrequested ICMP Echo packets, it could be a simple issue of false addressing or improper routing somewhere. However, if the analyst were to see that three separate network segments were reporting seven unrequested ICMP Echo packets, it is much more likely that these packets would be malicious in nature. This would cause the analyst to take note of the activity and perhaps check into the incident further or flag it for review at a later date. Analysis Case Study You come into the office early one morning, boot up your PC, and surf to your Central Analysis server to see what has been going on throughout the night. First thing you do is check incident reports aggregated by the attackers IP. You notice that slews of probes were sent to two internal use IIS Web Servers, located at 172.16.2.106, and 172.16.1.98. These segments’ agent Ids are “Main Office.” and “Production” The following shows up on the incident report: Source IP: 206.219.23.16
Now we’ll want to see if any other attacks were attempted on either of these machines. So, we’ll aggregate the attack data by the target IP addresses, which are included in the previous report. Now we get two reports. Target IP: 172.16.106
Target IP: 172.16.1.98
Next we’ll combine these two reports by asking the database to give us all attack data with an attacker IP of 24.26.198.98, and 209.219.23.16, against “Production” and “Main Office.” We’ll also have it sort by date and time: Source IP: 24.26.198.98 OR 206.219.23.16
This basically, gives us a step-by-step view of how the attack was carried out by the two attackers. This example is very simplistic, but there have been several demonstrated highly complex attacks that have been identified using this analysis method. Using these reports, it would be apparent to the analyst that a coordinated attack was attempted against both of these IIS servers. Further analysis can be achieved by viewing the actual IDS logs submitted to the central analysis server, and a decision on network vulnerability to attempted attacks can be performed, as per the GIAC standard for incident analysis reports. It would also be advisable to see the aggregated report on the second attackers IP, to see if any other systems had attack attempts from this system, that were not included in this coordinated attack. It has been demonstrated in the past that this system helps the analyst identify large scale, coordinated attacks against large corporate networks, attacks that might otherwise have gone unnoticed due to communications breakdowns between teams and the inability to correlate all the data involved across multiple network segments without a system like this. Conclusion The dIDS system gives the analyst a quicker, easier, more efficient method to identify coordinated attacks across multiple network segments, and to trace back the activities of the attackers. The system also, ultimately, saves the corporation whose networks it is deployed on money by reducing the number of Incident Analysts needed, as well as the amount of time required to gather logs from the various IDS systems setup in a large corporate network. By having all of these attack records stored in a single place, it allows the analyst much more flexibility in discovering attack patterns, and other attack issues which may have otherwise gone unnoticed. As attackers, and attack methods become increasingly complex, the need for a dIDS system in large corporate, and military networks increases drastically. With the increased complexity of these attacks, analysts are leaving themselves open to the problems of communications breakdowns, where one analyst sees a single attack on his segment, and dismisses it as nothing. While several other segments receiving the same attacks in a coordinated manner, their analysts may be dismissing the seriousness of the attack. However, when all the attack data is viewed together, a dramatically different perspective the attack may emerge. dIDS systems are the next logical level for IDS systems to move to. They are able to be setup with pre-existing architectures and IDS systems, making them even more cost-efficient. It should also be noted that there are currently a few systems in place that fall along the lines of a dIDS. Instead of being based in the corporate environment, focused on in this paper, they are deployed across the entire Internet, which thousands of sensors submitting data to them every day. One such service is SecurityFocus’s ARIS Predictor service, which should be noted due to its large scale demonstration of the use of a dIDS in the reporting of attacks to ISPs, server owners, and their proven ability to identify new worms, and attacks, therefore making the Internet as a whole safer for all. Nathan Einwechter is currently a Senior Research Scientist with Fate Research Labs, aswell as a System Developer/Incident Analyst with myNetWatchman.Com. While working with myNetWatchman, Nathan assisted in the discovery and analysis of the "W32.Leave.Worm" along with SANS, the FBI, and NIPC. The discovery of which was made possible by analysis of data collected by a dIDS system. |
برای آغاز شاید بد نباشد به سایتهای زیر سری بزنید. اطلاعات خوبی برای پیاده سازی یک کلاستر در آنها هست
http://www.mcsr.olemiss.edu/bookshelf/articles/how_to_build_a_cluster.html
همینطور راههای سادهتری هم هست٬ مثلاً از نرمافزارهای آمادهای که اینکار را انجام میدهند٬ استفاده کنید. به عنوان مثال:
OSCAR http://oscar.sourceforge.net
ROCKS http://www.rocksclusters.org
Scyld http://scyld.com
مثلاً اسکار به کاربر امکان میدهد٬ که بدون توجه به تجربهاش در محیطهای لینوکس٬ بتواند یک خوشه لینوکس راهاندازی کند.
منبع : http://www.blogger.com/profile/09208285748429855857
شرکت ردهت اقدام به معرفی نسخهی جدیدی از سیستم عاملهای خود نموده است که در این نسخه٬ محاسبات موازی٬ محاسبات روی گرید٬ و مسائلی از این دست که مورد علاقه محاسباتی کاران است بسیار قابل حصول شده است.
نسخهی بتای این سیستم عامل٬ اکنون قابلِ دانلود است.
به بخشی از توضیحات مربوطه توجه کنید:
Red Hat Enterprise MRG supports the full spectrum of distributed tasks, including:
* High-speed, reliable, or large file messaging
* Parallel & cycle-stealing scheduling
* High Performance Computing (HPC) and High Throughput Computing (HTC)
* Distributed workload management
Red Hat Enterprise MRG can run across multiple platforms but also takes deep advantage of Red Hat Enterprise Linux capabilities like clustering, IO, and virtualization for optimal performance and qualities of service.
مرجع:
http://www.redhat.com/mrg/?intcmp=70160000000HEmC
http://www.redhat.com/mrg/grid
منبع :
Middleware در يك سيستم محاسباتی توزيع شده به عنوان لايه نرمافزاری تعريف میشود كه بين سيستم عامل و برنامهها قرار میگيرد و اجرای چند فرايند را بر روی يك يا چند ماشين در شبكه امكان پذير میسازد.
Middleware برای انتقال برنامههای mainframe به برنامههای كلاينت / سرور ضروری است. اين تكنولوژی در سالهای 1990 تكامل يافت. تكنولوژیهای Middleware با رشد برنامههای مبتنی بر شبكه اهميت پيدا كردند. از سوی ديگر تعداد سيستمهايی كه از مجموعهای از ديوايسها تشكيل شده بودند افزايش يافت. هر ديوايس عملكردی را انجام میداد كه در شبكه با ساير ديوايسها نظير تلفنهای هوشمند، كامپيوترهای شخصی، PDA تعامل داشت.
عملكردهای Middleware
در هر يك از حالات فوق، برنامهها از نرمافزار ميانجی و پروتكلهای ارتباطی برای انجام عملكردهای زير استفاده میكنند:
پنهانسازی توزيع: توجه به اين واقعيت كه برنامه معمولا از بخشهای به هم پيوستهای تشكيل شده است كه در مكانهای توزيع شده اجرا میشود.
پنهان سازی ناهمگنی اجزای سختافزاری، سيستم عاملها و پروتكلهای ارتباطی مختلف
تهيه رابط استاندارد، يكپارچه و سطح بالا برای توسعهگران برنامهها، به گونهای كه برنامهها به سادگی قابل تهيه و استفاده مجدد باشند.
تهيه مجموعه سرويسهايی برای انجام عملكردهای مختلف همه منظوره.
اين لايههای نرمافزاری ميانجی، Middleware ناميده میشوند.
Middleware با فراهم آوردن محيط برنامهنويسی مشترك، پنهان سازی ناهمگونیها، توزيع سختافزار و سيستم عامل زيربنايی و پنهانسازی جزييات و برنامهنويسی سطح پايين، توسعه برنامهها را آسانتر میسازد.
برخی از انواع Middleware
Middleware بازتابی: اينگونه Middleware از تكنيكهای بازتابی برای رسيدن به انعطافپذيری و انطباق با پلاتفرمها استفاده میكند.
Middleware رويدادگرا: اين Middleware مفاهيم، طراحی، پيادهسازی و سرويسهايی را در بر میگيرد كه از سيستمهای رويدادگرا پشتيبانی میكنند.
Middleware شیگرا: Middleware شیگرا پارادايم برنامهنويسی شیگرا را برای سيستمهای توزيع شده بسط میدهد.
Middleware پيام گرا: اين Middleware در لايههای پايين مدل شبكه OSI به كار گرفته میشود. Middlewareهای مختلف از مدلهای بربرنامهنويسی متفاوت پشتيبانی مینمايند. Middleware شیگرا متداولترين Middleware است كه در آن برنامهها به صورت آبجكتهايی ساخته میشوند. CORBA و COM از جمله اين Middleware هستند. Middleware رويدادگرا برای ساخت برنامههای توزيع شده غيرمتمركز مناسب است. كنترل فرايند، شبكههای خبری اينترنتی از زمره اينگونه Middlewareها هستند.
Middleware پيامگرا برای برنامههايی كه در آنها پيامها به صورت دائمی ذخيره میشوند، مناسب است. برنامههای پيامرسانی و گردش كار نمونههايی از اينگونه Middleware هستند.
طراحی Middleware
Middleware به عنوان واسط بين بخشهای مختلف برنامه يا بين برنامهها عمل میكند. لذا قواعد به كار رفته در معماری نقش اساسی در طراحی Middleware دارند. در اينجا منظور از معماری، معماری كلی سازمانها و الگوهای ارتباطی در زمينه برنامهها و خود Middleware است. هر سيستم Middleware به لايه ارتباطی بستگی دارد. اين لايه امكان عمل بينابينی بخشهای مختلف را فراهم میآورد.
چالشهای فراروی Middleware
هزينهها: هزينه بكارگيری تكنولوژی Middleware در توسعه سيستمها كاملا به سيستم عاملها و پلاتفرمهای مورد نياز بستگی دارد. پيادهسازی Middleware منحصر به فروشنده آن است. لذا به پشتيبانی و نگهداری از جانب فروشنده وابسته است. اين وابستگی تاثير منفی بر انعطافپذيری و قابليت نگهداری سيستم دارد.
پيچيدگی برنامهها: هر چه برنامهها ارتباط درونی بيشتری با هم داشته باشند. تعداد آبجكتها با كاربران و ديوايسها افزايش میيابد. اين امر مديريت آبجكتها و پيچيدگی اداره نمودن سيستم را دشوار میسازد.
مديريت برنامهها: مديريت برنامههای بزرگ، ناهمگون و توزيع شده با مشكلات متعددی از قبيل مسائل امنيتی، نظارتی، وابستگی به چندين زير سيستم، تعريف و پياده سازی خط مشیهای مديريت منابع روبرو خواهد بود.
منبع : http://www.pcworldiran.com
جهش اطلاعاتي دنياي رايانه
اين نوشته يک گزارش علمي است از پروژه ملي ژاپن به اسم NAREGI که مخفف National Research Grid Initiative مي باشد که طي يک همايش بين المللي در معرض داوري دانشمندان و متخصصان سراسر دنيا قرار گرفت. نگارنده خود نيز در اين همايش شرکت داشت که جهت اطلاع دوستان محقق داخلي و مسولان مربوطه اين گزارش را تقديم مي نمايد. هدف اصلي پروژه NAREGI اين است که به قدرت محاسباتي پتا(10 به توان 15) فلاپ بر ثانيه دست بيابند. اين ميزان قدرت محاسباتي معادل يک ميليون پينتيوم 4 است. اين پروژه از سال 2003 تا 2007 با بودجه اي از حدود 20 ميليون دلار بر سال تعريف شده است. يعني براي کل پروژه 5 ساله 100 ميليون دلار بودجه پيش بيني شده است. شايد چيزي مثل درآمد نفتي يک روز ما!
قرار است با اين قدرت محاسباتي پتافلاپ بر ثانيه چه کاري بکنند؟ اين طوري که پروفسور H. Nakamura رييس انيستيتوي علوم مولکولي نارا- ژاپن ميگفت اهداف به اين شکل است: 1- به وجود آوردن و نهادينه کردن علم جديدي به اسم علم نانو (نه تکنولوژي نانو) به عنوان يکي از علوم پايه. به نظر نگارنده روحيه متواضع و بي ادعاي ژاپني به سختي مي تواند ادعايي از اين نوع داشته باشد و اگر يک دانشمند ژاپني چنين ادعايي بکند بايد خيلي آن را جدي گرفت! 2- مفهوم GRID را به عنوان ابزار طبيعي اين علم درآورند. GRID يک محيط محاسباتي ناهمگون است که مساله ترجمه کدهاي کامپيوتري بين سيستم عاملهاي مختلف را مرتفع خواهد کرد. در حقيقت GRID خود يک سيستم عامل است که توسط ابزارهايي به اسم middleware امکان ارتباط بين کدهاي توسعه يافته تحت سيستم عاملهاي مختلف را فراهم مي کند. براي توسعه سيستم عامل GRID و middlewareهاي مربوطه حدود 300 مهندس کامپيوتر مطابق گفته معاون وزير علوم ژاپن در اين پروژه مشارکت دارند. تاکنون ژاپنيها توانسته اند به طور موفقيت آميزي چند برنامه را به عنوان مثالي از عملي بودن اين محيط محاسباتي با استفاده از سيستم GRID حل نمايند: شبيه سازي مولکولهاي بزرگ از حدود پروتيينها در خلا با قدرت محاسباتي فعلي به صورت کاملا کوانتومي وجود ندارد. وجود حلال (يعني 10 به توان 23 مولکول آب!) مساله را از اين نيز پيچيده تر ميکند.ولي با استفاده از قدرت فعلي محاسباتي از حدود 17 ترا (10 به توان 12) فلاپ بر ثانيه ژاپنيها توانسته اند برخي واکنشهاي شيميايي در محلولها و من جمله فرايندهاي حياتي مربوط به پروتيينها را شبيه سازي کنند. اين ميزان قدرت محاسباتي توسط حدود سه هزار رايانه در سرتاسر ژاپن تامين ميشود که توسط شبکه فوق سريع به هم مربوط اند.
هدف غايي اين است که بتوانند قطعات الكترونيك مقياس نانومتر (مشتمل بر حدود يک ميليون الکترون) را بدون ساختن قطعات در آزمايشگاه بر روي سيستم GRID شبيه سازي کنند. البته کاربرد سيستم GRID به شبيه سازيهاي کوانتومي و فرايندهاي شيميايي يا کاربردهاي آن در ماده بيولوژيک منحصر نيست. نکته جالب توجه اين است که حدود 40 کمپاني مهم ژاپني نظير هيتاچي و تويوتا نيز در اين پروژه مشارکت دارند. مثلا يکي از کاربردهاي بالقوه اين محيط محاسباتي ميتواند شبيه سازي تصادف خودروها با جزييات بيشتر و دقيق تر باشد.
نکاتي هم از بحث با برخي دانشمندان اروپايي و آمريکايي که به اين همايش دعوت شده بودند نقل ميکنم: پروفسور Sandro Sorella از مرکز SISSA در ايتاليا معتقد است که هرچقدر که تعداد زيادتري کامپيوتر از مراکز مختلف را بتوان تحت تکنولوژي GRID به هم متصل کرد، به همان ميزان نيز متقاضي استفاده از شبکه و اجراي برنامه در شبکه افزايش خواهد يافت که عملا فرقي بين استفاده از GRID يا عدم استفاده از آن وجود ندارد. پروفسور Takami Tohyama از انيستيتوي تحقيقات مواد دانشگاه توهوکو ژاپن در جواب اين سوال من که شما تميز ترين کد قطري سازي دقيق دنيا را در طي 15 سال گذشته توسعه داده ايد حاضريد اجازه دهيد کس ديگري آن سوي دنيا کد شما را کامپيايل کرده و از آن استفاده کند گفت که اين يک روياست! تحقق آن سخت به نظر ميرسد. يک پروفسور روسي الاصل از کانادا هم که متخصص محاسبات بزرگ مقياس است معتقد بود که اگر به فرض به هدف پتافلاپ برسند فقط قدرتشان 1000 برابر قدرت محاسباتي نوعي خوشههاي 512 تايي است که به معناي 10 برابر شدن ابعاد فضايي يک سيستم 3 بعدي است و اشتهاي ما را براي سيستمهاي بزرگتر برخواهد انگيخت. چون هنوز اين ميزان كافي نيست.
پروفسور G. Baskaran از انيستيتوي علوم رياضي مدرس هندوستان معتقد است راه حل مسايل پيچيده در فيزيک ماده چگال يا ماده بيولوژيک کامپيوترهاي بزرگ نيست! وقتي يک مساله جديدي با ميزان پيچيدگي جديد فرا روي ما قرار ميگيرد، براي حل آن نياز به ابداع «مفهوم» جديد داريم. به نظر نگارنده نيز اين استاد بزرگوار در حالت کلي فرمايششان متين است. اما به هر صورت کشور ما براي بسياري از مسايل به قدرت محاسباتي از حدود چند ده ترافلاپ بر ثانيه (معادل چند هزار پنتيوم 4) براي برخي پروژههاي ملي نياز دارد.
اگر قرار است که اين ميزان قدرت محاسباتي با چيزي مثل چند ده ميليون دلار حاصل شود براي مملکت ما کار سختي نيست. فقط کافي است که کار را به کاردان بسپارند!! مملکت ما در حال حاضر در شيمي داراي دانشمنداني است که توسط استانداردهاي بين المللي به عنوان دانشمند پر استناد معرفي شده اند. در فيزيک هم تا آنجايي که نگارنده خود به عنوان محقق فيزيک مطلع است دانشمندان قابلي در اين کشور وجود دارند. درعلوم کامپيوتر با اينکه رشته تخصصي بنده نيست ولي بچههايي که قادرند در سطح اسباب بازي (مسابقه فوتبال روباتها) در دنيا اول شوند به وضوح مي توانند در سطوحي جدي تر و کاربردي تر از اين حرفها شانه به شانه دوستان ژاپني ما پيش بروند. در رشتههاي ديگر نيز مطمئنا کساني هستند که در صورت اعتماد به آنها قاردند کارهاي مهمي انجام دهند.
نکته آموزندهاي که از اين همايش ژاپني مي توان آموخت اين است که روحيه پاسخگويي دانشمندان ژاپني ايجاب ميکند که به ازاي پول 20 ميليون دلار بر سالي که تاکنون استفاده کرده اند، چند تا از برجسته ترين دانشمندان شيمي (به عنوان مثال پر استناد ترين دانشمند شيمي دنيا در اين همايش شرکت داشت)، فيزيک و متخصصان محاسبات بزرگ مقياس را از آمريکا و اروپا دعوت کنند تا در حضور آنها به سنت حسنه «پاسخگويي» بپردازند! هيچ چيز سري هم وجود ندارد! همه به صورت آزاد دعوت شده اند تا نظر دهند. اگر کسي اشکالي در سيستم و رهيافت علماي ژاپني به ذهنش برسد و به آنها تذکر دهد با لبخند مليح ژاپني و ادب و تشکر فراوان آنها مواجه خواهد شد.
منبع : http://www.bashgah.net
كامپيوترهاى كوانتومى
ترجمه: شايان شهند
كامپيوترى كه روى ميز تحرير شما جا خوش كرده، براى كاركردن بايد يك مشت صفر و يك را بفهمد و دستكارى كند. همه اطلاعات اعم از حروف و اعداد يا وضعيت مودم و موس شما با مجموعه اى از بيت هاى متشكل از صفرها و يك ها به كامپيوتر داده مى شود. اين بيت هاى اطلاعات، خيلى ساده همان طورى تعريف مى شوند كه فيزيك كلاسيك دنيا را تعريف مى كند؛ سوئيچ هاى الكتريكى مى توانند روشن يا خاموش باشند، اشيا مى توانند اينجا باشند، مى توانند هم نباشند! ولى كامپيوترهاى كوانتومى با طبيعت دودويى هاى فيزيك كلاسيك محدود نمى شوند همه اش به اين بستگى دارد كه حالت بيت هاى كوانتومى يا همان كوبيت ها را چطور ببينيم؛ كوبيت ها ممكن است نشانگر يك صفر يا يك يك، تركيبى از اين دو يا حتى معرف عددى باشند كه حالت آنها را جايى بين صفر و يك تعيين مى كند. با توجه به فيزيك كوانتومى، نمى توان دقيقاً وجود يا عدم وجود يك ذره ريز درون اتمى را مشخص كرد. مى توان به وسيله آمار و احتمال، امكان وجود اين ذره هاى ريز را در مكان و زمان مشخصى تعيين كرد، اما هيچ راهى براى دانستن قطعى اين كه آيا اين ذره آنجا هست يا نه، تا وقتى كه آن را مستقيماً نديده ايم وجود ندارد. البته آنچه كه در كامپيوترهاى كوانتومى با ارزش است همين احتمالات است. اين احتمال بودن يا نبودن است كه نبودن يا بودن كامپيوترهاى كوانتومى را تعيين مى كند.
قدرت زياد پردازنده هاى كنونى هنوز نتوانسته تشنگى بشر به سرعت و ظرفيت محاسبات را برطرف كند. در سال 1947 مهندس آمريكايى «هووارد آيكن» گفت كه فقط 6 كامپيوتر ديجيتال الكترونيكى نياز محاسباتى تمام ايالت متحده را بر طرف مى كند. ديگران هم پيش بينى هاى مشابهى را درباره ميزان قدرت محاسباتى لازم براى برطرف كردن نياز هاى تكنولوژيكى روبه رشد انجام دادند. البته «آيكن» حجم زياد اطلاعاتى كه از تحقيقات علمى ايجاد مى شد را به حساب نياورده بود، گستردگى كامپيوتر ها به عنوان بخشى از زندگى روزمره انسان قرن جديد و ضرورت اينترنت به تنهايى مى تواند نياز بشر به قدرت محاسبات را چند برابر كند. آيا انسان به قدرت مورد نياز خود براى محاسبه و پردازش اطلاعات دست خواهد يافت؟
اگر همان طور كه «قانون مور» مى گويد، تعداد ترانزيستور هاى موجود در يك ريزپردازنده هر هجده ماه دو برابر شود _ و اين روند با همين سرعت ادامه داشته باشد- در سال 2020 يا 2030 مدار هاى روى ريز پرداز نده ها بايد در مقياسى اتمى اندازه گيرى شوند. قدم بعدى كامپيوتر هاى كوانتومى است. كامپيوتر هايى كه با مهار كردن انرژى اتم ها و مولكول ها، از آنها به عنوان حافظه و پردازنده استفاده خواهند كرد. كامپيوتر هاى كوانتومى مى توانند محاسبات را ميليارد ها برابر سريع تر از هر كامپيوتر سيلي-ى ديگرى انجام دهند. دانشمندان پيش از اين كامپيوتر هاى كوانتومى ساده اى كه توانايى انجام محاسبات مشخصى را داشته اند، طراحى كرده اند اما هنوز با يك كامپيوتر كوانتومى كاربردى فاصله زيادى دارند. براى رسيدن به زمان پيدايش ايده كامپيوتر هاى كوانتومى لازم نيست زياد به عقب برگرديم.
تئورى كامپيوتر هاى كوانتومى بيست سال بيشتر ندارد. در سال 1981 فيزيكدان آزمايشگاه Argonne National، «پل بنيوف» اولين تئورى كاربرد نظريه كوانتومى در كامپيوتر ها را منتشر كرد. ايده «بنيوف» ايجاد يك ماشين تورينگ كوانتومى بود. اغلب كامپيوتر هاى ديجيتالى، مثل همين كامپيوتر هايى كه من و شما با آن كار مى كنيم، براساس «نظريه تورينگ» طراحى شده اند. ماشين تورينگ كه در سال 1930 توسط «آلن تورينگ» معرفى شد از يك نوار حافظه با طول نامحدود و يك هد خواندن و نوشتن تشكيل شده بود. اين نوار حافظه به خانه هاى كوچكى تقسيم مى شد كه هر كدام مى توانست حاوى صفر يا يك باشد يا اينكه خالى بماند. دستگاه خواندن و نوشتن با فرمان گرفتن از ماشين مى توانست حركت كند، علائم را بخواند يا تغييرى در آنها ايجاد كند. اين چه ربطى به كامپيوتر هاى كوانتومى دارد؟ در يك ماشين تورينگ كوانتومى اين نوار حافظه و دستگاه خواندن و نوشتن حالت كوانتومى دارد. يعنى اينكه علائم روى نوار مى توانند صفر، يك يا مقدارى بين صفر و يك باشند. به علاوه ماشين تورينگ فقط يك محاسبه در هر لحظه انجام مى دهد، حال آنكه نوع كوانتومى آن مى تواند تعداد زيادى محاسبه را در آن واحد به انجام برساند. كامپيوتر هاى امروزى مثل ماشين تورينگ با دستكارى بيت هايى كه در يكى از دو حالت صفر يا يك هستند كار مى كنند. ولى كامپيوتر هاى كوانتومى به دو حالت محدود نمى شوند. آنها اطلاعات را در قالب كيوبيت ها دريافت مى كنند.
محتويات يك كيوبيت همان طور كه گفته شد صفر، يك، هر دو يا چيزى بين اين دو است. كيوبيت ها در واقع اتم هايى هستند كه با هم كار مى كنند تا يك حافظه يا پردازنده را به وجود آورند. اينكه كامپيوتر هاى كوانتومى مى توانند در يك زمان چندين حالت داشته باشند به آنها اين امكان را مى دهد كه ميليون ها بار سريع تر و قدرتمند تر از ابركامپيوتر هاى فعلى كار كنند. چند حالت پذيرى كيوبيت ها همان دليلى است كه باعث مى شود كامپيوتر هاى كوانتومى ذاتاً از پردازش موازى بهره ببرند. پردازش موازى امكان كار كردن بر روى ميليون ها محاسبه در يك لحظه را به اين كامپيوتر ها مى دهد در حالى كه كامپيوتر شخصى شما فقط يك محاسبه در لحظه انجام مى دهد.
يك كامپيوتر كوانتومى 30 كيوبيتى قدرتى معادل كامپيوترى معمولى با توانايى انجام 10 ترا محاسبه بر روى اعداد اعشارى در يك ثانيه _ ترافلاپس (Teraflops)- دارد. سريع ترين ابركامپيوتر كنونى سرعتى برابر 2 ترافلاپس دارد.
پژوهشگران شركت IBM با استفاده از تكنيك هاى تشديد مغناطيسى هسته اى (NMR) يك كامپيوتر كوانتومى ساخته اند كه اسپين اتم هاى مجزا را اندازه گيرى و دستكارى مى كند. انفجار انرژى امواج راديويى مى تواند با تغيير سطح انرژى يك اتم، پروسه شمارش را شروع كند. پروسه اى كه در تقابل با ساير اتم ها و به صورت كنترل شده اى مى تواند الگويى از شمارش كوانتومى را به وجود آورد. الگويى كه مى تواند به جواب حاصل از كامپيوترهاى معمولى مربوط باشد.
دلايل زيادى براى اين همه تلاش پژوهشگران جهت ساخت و توسعه كامپيوترهاى كوانتومى وجود دارد. اول اينكه اتم ها مى توانند حالت انرژى خود را با سرعت فوق العاده اى تغيير دهند، سرعتى كه نهايتاً باعث افزايش سرعت پردازش اطلاعات كامپيوترها مى شود. ديگر اينكه اگر مسئله اى كه به هر كيوبيت داده مى شود با ذات كامپيوتر كوانتومى سنخيت داشته باشد هر كيوبيت مى تواند جاى يك پردازنده كامل را بگيرد. يعنى اينكه 1000 يون باريوم مى توانند به جاى 1000 پردازنده كامپيوتر كار كنند! كليد استفاده از اين قابليت يافتن گونه مسائلى است كه يك كامپيوتر كوانتومى مى تواند حل كند. خيلى بعيد است كه روزى شما شاهد حضور يك كامپيوتر كوانتومى روى ميز كارتان باشيد. چرا كه اين كامپيوترها براى انجام كارهايى چون پردازش متون يا چك كردن اى ميل طراحى نشده اند. از طرفى ديگر رمزگشايى و رمزگذارى در ابعاد وسيع براى كامپيوترهاى كوانتومى ايده آل است. و كاركردن با پايگاه هاى داده بزرگ جزء بخش هايى است كه مسلماً كامپيوترهاى كوانتومى حرف اول را در آن خواهند زد.
كامپيوتر هاى كوانتومى مى توانند روزى جاى كامپيوتر هاى سيلي-ى را بگيرند همان طور كه ترانزيستور ها حباب هاى خلأ را از ميدان به در كردند. البته امروزه تكنولوژى مورد نياز براى اين كامپيوتر ها چندان پيشرفت نكرده است. اغلب تحقيقات در باب كامپيوتر هاى كوانتومى هنوز در حد تئورى اند. پيشرفته ترين كامپيوتر كوانتومى حاضر هنوز از پس كار كردن با بيش از 7 كيوبيت برنيامده است. يعنى آنها هنوز در مرحله 2=1+1 هستند. علاوه بر اين، آنچه كه كامپيوتر هاى معمولى امروزى به زحمت و به كندى انجام مى دهند، كامپيوتر هاى كوانتومى، به سرعت و در كسرى از ثانيه انجام خواهند داد.
كامپيوتر هاى كوانتومى مى توانند فاكتوريل اعداد بزرگ را در كسرى از ثانيه محاسبه كنند. از آنها مى توان براى جست وجو در پايگاه هاى داده بزرگ و رمز گذارى و رمز گشايى استفاده كرد. اگر امروز يكى از آنها وجود داشت ديگر هيچ، اطلاعاتى بر روى اينترنت امن نبود. سيستم هاى ساده كد گذارى امروز در برابر سيستم هاى پيچيده كامپيوتر هاى كوانتومى فردا حرفى براى گفتن نخواهند داشت.
وجود اينچنين كاربردهاى وسيع و مهمى است كه دانشمندان را به كار بر روى كامپيوترهاى كوانتومى مشتاق كرده است. اگرچه دانشمندان و مهندسان تعدادى كامپيوتر كوانتومى كوچك ساخته اند ولى در راه توليد و توسعه كامپيوترهاى كوانتومى تجارى كارا مشكلات مهمى وجود دارد. مهمترين آنها حفظ يك يون در حالت پايدار، هنگام مشاهده سطح انرژى و جهت اسپين آن است. در حال حاضر يون ها با استفاده از ليزر در دمايى نزديك به صفر مطلق نگهدارى مى شوند. اين كار را بعد از جداسازى يك اتم از گروهى و قرار دادن آن در جاى خودش انجام مى دهند. تا به حال گونه هاى ارائه شده از كامپيوترهاى كوانتومى چيزى بين دو تا چهار اتم داشته اند. تكنيك هاى NMR كه به وسيله IBM استفاده شده است راهى براى تحقيق درباره تاثير حالت يون ها بدون مشاهده مستقيم آنها ارائه مى دهد. مشاهده مستقيم يون ها منجر به از بين رفتن احتمالات و لفظ «هردو يا چيزى بين صفر و يك» خواهد شد، اين يعنى نابود كردن بنياد كامپيوترهاى كوانتومى.
اما كامپيوتر هاى كوانتومى هنوز راه زيادى براى پيمودن و پيشرفت دارند. آنها براى مواجه شدن با مشكلات دنياى واقعى بايد حداقل چندين جين كيوبيت داشته باشند.
از كامپيوتر هاى كوانتومى مى توان براى رمز گذارى و رمز گشايى استفاده كرد اگر امروز يكى از آنها وجود داشت ديگر هيچ اطلاعاتى بر روى اينترنت امن نبود.
منبع: http://www.hupaa.com/Data/P00269.php
MultiThreading چیست؟
مقدمه -
گاهی اوقات ممکن است که شما بخواهید برنامه شما دو یا چند عمل را به طور همزمان انجام دهد و یا اینکه نیاز به انجام عملیاتی که مدت زمان زیادی به طول می انجامد و یا زمان انجام آن معلوم نیست ، باشد ، بدون اینکه برنامه شما از دسترس کاربر خارج شود و به اصطلاح برنامه شما تا پایان یافتن عملیات قفل کند و همچنین کاربر بتواند عملیات را متوقف/معلق/شروع دوباره نماید . در چنین موقعیتی نیاز به MultiThreading حس میشود . به فرض مثال کد زیر را در نظر بگیرید :
For i As Integer = 0 To 10000000
For i2 As Integer = 0 To 100
'Do Nothing
Next
Next
هنگامی که این عملیات شروع میشود ، کاربر توانایی کار با برنامه تا پایان یافتن آن را نخواهد داشت .
Thread چیست؟
Thread نامی برای جریان اجرای یک عملیات خاص میباشد و هنگامی که برنامه شما دارای چند Thread میباشد بدان معناست که قسمت های مختلفی از کد برنامه شما به طور همزمان در حال اجرا شدن میباشند . در حقیقت کامپیوتر زمان پردازش یک عملیات را به قسمت(slice) های مختلفی تقسیم میکند و هنگامی که شما یک Thread جدید را آغاز میکنید کامپیوتر قسمتی از زمان را به آن اختصاص میدهد . لازم به ذکر است که برنامه شما از ابتدا دارای یک Thread اصلی (Main Thread) برای اجرا کد مربوط به آن میباشد .
کار خود با Thread ها را آغاز مینماییم :
میخواهیم برنامه ای بنویسیم که تا یک عدد معین عملیات شمارش را انجام دهد .
1 – یک پروزه Windows Apploication به نام MutiThreading Sample ایجاد نمایید .
2 – یک Button به نام btnStart و یک TextBox به نام txtMAX به فرم اضافه نمایید .
3 – یک کلاس به نام clsCounter به پروژه اضافه کرده و کد زیر را در داخل آن قرارهید :
Public Class clsCounter
Public MAX As Integer
Public Event CountingFinished(ByVal Number As Integer)
Sub StartCounting()
Dim intTotal As Integer
For i As Integer = 0 To MAX
intTotal += 1
Next
RaiseEvent CountingFinished(intTotal)
End Sub
End Class
توضیحات در مورد کد فوق :
• وظیفه این کلاس شمردن از 1 تا مقدار MAX میباشد .
• رویدادی با نام CountingFinished تعریف کردیم که هنگامی که عملیات شمارش به پایان برسد اتفاق می افتد .
• متد StartCounting از 1 تا مقدار intMax را شماره کرده و در هر بار اجرای حلقه یک واحد به مقدار متغیر intTotal اضافه میشود که در نهایت مساوی با مقدار MAXخواهد بود .
• پس از پایان شمارش رویداد CountingFinished را همراه با پاس کردن متغیر intTotal به آن اجرا مینماییم .
حال ما باید در هنگامی که دکمه کلیک میشود یک Thread جدید ایجاد کرده و سپس متد StartCounting کلاس clsCounter را اجرا کرده و رخدادن رویداد CountingFinished را کنترل نماییم . در زمانی که عملیات شمارش انجام میشود ما میتوانیم رابط کاربری را کنترل کرده و کاربر توانایی کار با برنامه را دارد .
حال کد زیر را به پروژه خود اضافه نمایید :
Sub CountingFinishedEventHandler(ByVal N As Integer)
System.Windows.Forms.MessageBox.Show("Counting Finished!")
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnStart.Click
Dim CounterClass As New clsCounter
Dim CountingThread As New Threading.Thread(AddressOf CounterClass.StartCounting)
CounterClass.MAX = Val(txtMax.Text)
AddHandler CounterClass.CountingFinished, AddressOf CountingFinishedEventHandler
CountingThread.Start()
End Sub
توضیحات در مورد کد فوق :
•ابتدا یک پروسیجر برای کتترل رویداد CountingFinished مربوط به کلاس Counter ایجاد مینماییم . هنگامی که رویداد اتفاق بیافتد(عملیات شمارش به پایان برسد) ، پیغامی مبنی بر پایان یافتن عملیات به کاربر نشان داده خواهد شد .
• در رویداد Click شی ء btnStart ، ابتدا یک نمونه از کلاس CounterClass ایجاد مینماییم .
• سپس برای ایجاد شی ء Thread ، آدرس متذ clsCounter.StartCounting را به سازنده کلاس Thread پاس مینماییم به طوری که متد clsCounter.StartCounting را بعد از آوردن کلمه کلیدی addressof ، می آوریم .
• بعد ، توسط کلمه کلیدی Addhandle ، کنترل کننده رویداد که CountingFinishedEventHandler نام دارد را به رویداد clsCounter.CountingFinished متصل مینماییم .
• در آخر نیز توسط متد Start مربوط به شیء CountingThread ، عملیات را آغاز مینماییم .
برخی متدهای دیگر مربوط به شی ء Thread :
Suspend و Resume : در حالی که یک Thread در حال اجراست ، توسط متد Suspend میتوانید آن را معلق کنید که منجر به متوقف شدن آن تا زمانی که متد Resume اجرا شود ، خواهد گردید .
Abort : Thread را متوقف میکند .
Sleep : توسط این متد میتوانید اجرای Thread را برای پاره ای از زمان (برحسب میلی ثانیه) به حالت تعلیق دربیاورید .
اولویت بندی Thread ها :
شما کنترل بیشتری بر روی Threadها دارید و میتوانید مقدار زمانی که هر Thread نسبت به دیگر Thread ها دریافت میکند را از طریق خاصیت Priority تنظیم نمایید . این خاصیت توسط یکی از ثابت های شمارشی زیر که عضوی از ThreadPriority میباشد تنظیم میشود :
ThreadPriority.AboveNormal : اولویت بالاتری به Thread میدهد .
ThreadPriority.LowerPriority : اولویت پایین تری به Thread میدهد .
ThreadPriority.HighestPriority : بالاترین اولویت را به Thread میدهد .
ThreadPriority.LowestPriority : پایین ترین اولویت را به Thread میدهد .
ThreadPriority.Normal : تولویت نرمال را به Thread میدهد .
پیدا کردن وضعیت Thread :
وضعیت یک Thread را میتوانیم به وسیله خاصیت ThreadState به دست بیاوریم که به وسیله یکی از ثابتهای شمارشی System.Threading.ThreadState معین میگردد .
System.Threading.ThreadState.Initialized : بیان میکند که Thread مقداردهی اولیه شده اما هنوز شروع نگردیده است .>System.Threading.ThreadState.Ready : Thread آماده است .
System.Threading.ThreadState.Running : بیان میکند که Thread در حال اجرا است .
System.Threading.ThreadState.Standbye : بیان میکند که Thread در حالت آماده به کاراست .
System.Threading.ThreadState.Initialized :بیان میکند که Thread به پایان رسیده است .
System.Threading.ThreadState.Transition : بیان میکند که Thread بین دو وضعیت بوده و در حالت انتقال از وضعیتی به وضعیت دیگر است .
System.Threading.ThreadState.Unknown : بیا میکند که وضعیت Thread معلوم نیست .
System.Threading.ThreadState.Wait : بیان میکند که Thread در حالت انتظار است .
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim Thread1 As New Threading.Thread(AddressOf test)
Thread1.Start()
Dim Thread2 As New Threading.Thread(AddressOf test)
Thread2.Start()
End Sub
Public Sub test()
MsgBox("test")
End Sub Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
test()
test()
End Sub
Public Sub test()
MsgBox("test")
End SubGTCMPS94 (سيستم هاي كنترل توزيع شده DCS)
مقدمه
يكي از مقوله هايي كه امروزه در زمينه اتوماسيون مورد توجه قرار گرفته است ، مسئله ايجاد شبكه كامپيوتري براي كنترل فرآيندهاي صنعتي است ، يكي از اين سيستمها، سيستم كنترل توزيع شدهDCS ميباشد .
پيشرفت سريع كامپيوتر و كاربرد آنها در سيستم هاي كنترل ، در چند سال اخير افزايش حيرت انگيزي كرده است ، اين پيشرفت سريع در كشور ما نيز با سرعت كمتري نفوذ كرده و بسياري از كارخانجات كشور مجهز به سيستم هاي كنترل كامپيوتري گسترده و نيمه گسترده شده اند.صنعت توليد برق بي شك يكي از پيشگامان اين عرصه مي باشد .
تحقيق زير مطالب جمع آوري شده و انتخاب شده اي از مدرك Elsag Bailey process automation و جزوات I&C Maintenance و مدارك بهره برداري ابزار دقيق توربين گاز V94 و مدارك گسسته شركت Ansaldo و تجربيات عملي ميباشد .
فصل 1 - GTCMPS94
سيستمي الكترونيكي بوده كه صرفاً به منظور كنترل نظارت و حفاظت توربوژنراتور V94.2 به كار گرفته شده است . سيستم GTCMPS94 يك سيستم كنترل توزيع شده (DCS) ميكروپروسسوري ميباشد كه در اين تحقيق سعي شده است قسمتهاي مختلف آن بررسي گردد .
تمامي تجهيزات سخت افزاري اين سيستم در تابلوهاي اتاق كنترل واحد نصب گرديده اند .
GTCMPS94 در پردازش ، مدارهاي واسط ، ارتباطات و منبع تغذيه داراي افزونگي ( Redundant ) مي باشد .
GTCMPS94 به منظور كنترل تمام اتوماتيك مجموعه توربين گاز و ژنراتور و انجام وظايف اصلي زير طراحي شده است :
- راه اندازي ، بهره برداري ، و Shut-down خودكار
- كنترل راه انداز (Drive Control)
- كنترل سوخت
- اتصال واحد به شبكه (Synchronization )
- نظارت (Monitoring)
- حفاظت توربوژنراتور
ساختار شبكه استفاده شده براي اين سيستم بر اساس استاندارد TCP/IP مي باشد
پيكر بندي استاندارد سيستم
ساختار GTCMPS94 شامل :
• يك مجموع از تابلوها ، شامل بردهاي ميكروپروسسوري ، افزونگي منبع تغذيه ، بردهاي I/O و اتصالات
• ايستگاه واسط اپراتوري (Operator Interface Unit ياOIU ) نوع Stand-alone براي اتاق كنترل واحد شامل مونيتور ، صفحه كليد ، موس و چاپگر آلارم ( براي هر واحد )
• ايستگاه واسط اپراتوري نوع روميزي (Desk Top) براي اتاق كنترل مركزي شامل مونيتور ، صفحه كليد موس وچاپگر آلارم ( براي هر واحد )
• يك كنسول مهندس شيفت براي هر نيروگاه بايد در نظر گرفته شود . كنسول سرمهندس شيفت امكان هر گونه دسترسي به سيستم را در اختيار بهره بردار قرار مي دهد . اين كنسول بايد توانايي كنترل و نظارت بر هر يك از توربين هاي گازي مدول را داشته باشد . Refresh Time اين كامپيوتر براي صفحات تصويري حداكثر 2 ثانيه است .
• يك ايستگاه كاري مهندسي به عنوان يك دستگاه ويژه تعميرات كه مي تواند براي مجموعه نيروگاه در نظر گرفته شود اين كامپيوتر در يك اتاق مخصوص ( جنب اتاق فرمان اصلي نيروگاه ) قرار مي گيرد و مي تواند دسترسي به همه مدول هاي متصل به سيستم را با امكانات ويژه خود فراهم سازد . اين امكانات شامل سفارشي كردن سيستم ، اصلاح اطلاعات پيكر بندي ، ايجاد صفحات جدد تصويري يا اصلاح صفحات قديمي و انجام هر گونه برنامه هاي عيب يابي و تشخيص خطا مي باشد.
• SER براي 128 سيگنال با دقت زماني 1 msec .
• تابلوي توزيع انرژي
• تابلوي ابزار دقيق نظارتي توربين
GTCMPS94 از طريق شاهراه اطلاعاتي اجازه اتصال و توسعه سيستم به ايستگاه واسط اپراتور راه دور و يا سيستم هاي خارجي مرتبط با ساير واحدها را مي دهد .
ساختار سيستم بايستي بر مبناي استفاده از ريز پردازنده هاي 32 بيتي با سطح افزونگي تشريح شده در زير باشد . همچنين سيستم بايد توانايي مديريت 1800 ورودي / خروجي با 20% ظرفيت يدكي ، كه 10% آن نصب و تست شده است داشته باشد .
براي اطمينان از صحت عمل سيستم كنترل ، GTCMPS94 داراي افزونگي در سطوح زير مي باشد .
• پردازش ها
• مدارهاي واسط
• ارتباطات
• منبع تغذيه
كليه وظايف كنترل ، حفاظت و نظارت در كارت هاي پردازش كننده (MFP) با افزونگي دو تايي اجرا مي گردند پيكر بندي سخت افزاري به صورت Hot-Stanby مي باشد .
در اين جفت پردازشگر ، يكي از پردازشگرها به صورت فعال و ديگري به صورت پشتيبان عمل مي كند . درحالت عادي MFP اوليه كار عادي خود را انجام داده و MFP ديگر به صورت Hot-Stanby مي باشد به اين معنا كه چنانچه MPF اوليه دچار خرابي شود ،MFP دوم بدون هيچگونه اختلاف در روند كنترل اتوماتيك وارد عمل شده و كنترل سيستم را به عهده مي گيرد ، در چنين مواردي يك آلارم در سيستم فعال مي گردد . در اين حال MFP خراب را در حين كار واحد ، بدون هيچ مشكلي مي توان تعويض نمود .
منبع : http://www.autoir.com/page.php?id=97
چرا دو پردازنده بهتر از یك پردازنده است...
|
برای بالا بردن قدرت كامپیوتر، مردم به لطایفالحیل زیادی متوسل میشوند، كه یكی از متداولترین آنها، دو قلو كردن، یا سه قلو كردن، یا حتا چهار قلو كردن پردازندههاست. |
|
Symmetric MultiProcessing (SMP)
منبع: |
Code Mobility and Session State
Code mobility as provided for by Request Based Distributed Computing RBDC (see backgrounder) is key for delivering On-Demand computing, Distributed Computing (e.g. SETI@home) and Rich Internet Applications.
RBDC enables the mobility of code that gets its input from http sources (url, request body, cookie, and passwordless GETs). This post looks into whether session state can be made mobile as well.
In a typical scenario, http servers associate session state with client request streams through the use of a server-unique session-id that is preserved between accesses via a cookie. An example of this is PHP’s handling of sessions. Under this scheme the server held session state prevents the code being mobile. The code is not mobile because the session state is only available in the server that generated the client’s requested resource.
Using RBDC, code that relies on session state can be made securely mobile. Here is one way.
[[Since writing this post, I have realised that the mechanism described here is the same mechanism that makes Google Reader Public Pages both globally available and private.]]
Firstly, the server stores the session state using a globally-unique-id (GUID) insead of server-unique-id as the key. The key is preserved between requests in the client cookie as is now done. Then the server makes the session state publically available at a well known URL. For example, an xml serialised version of the state could be GET and POSTable at a URL like https://www.myserver.com/sessionstate. The GUID used is sufficiently long to prevent guessing and therefore session state will be securely and globally available.
With session state stored in such a secure and globally available fashion, code that requires session state may also be mobile.
منبع : http://www.davidpratten.com
اعمال هم زمان در پایتون ( بخش دوم )
استفاده از تکنیک چند نخی رو ساده تر کنه.
استفاده از تکنیک چند نخی رو امن تر کنه.
تغییر در مفسر رو راحت تر کنه.
توسعه ی مفسر رو راحت تر ساده تر کنه.
اما از طرفی هم :
نمی ذاره چند نخ به طور هم زمان اجرا بشن و فقط می تونه همزمانی رو شبیه سازی کنه.
نمی تونه از پردازنده ها و یا هسته های اضافی CPU استفاده کنه و همه ی کارها رو روی یه هسته انجام میده.
یه نکته ای که قابل ذکر هستش اینه که مفسر به کدهای خارجی کاری نداره. مثلا اگه تولکیت Qt از چند نخی استفاده می کنه, استفاده از اون در پایتون باعث تحت پوشش قرار گرفتن کار Qt توسط GIL نمیشه و اون خیلی راحت می تونه به طور واقعی از چند نخی استفاده کنه. البته موقع نوشتن رابط پایتون برای همچین برنامه هایی باید به یه سری نکاتی هم توجه بشه تا باعث به وجود اومدن مشکل نشه.
کاربران پایتون خواستار برداشته شدن این ساختار از مفسر هستن تا بتونن به طور واقعی از چند نخی استفاده کنن و همچنین از منابع اضافی مثل CPU های چند هسته ای هم بهره ببرن. ولی به دلایلی این کار به همین راحتی ها قابل انجام نیست:
GIL در سرتاسر مفسر استفاده شده و حذف اون اصلا ساده نیست.
حذف GIL می تونه باعث بشه مفسر یه بار دیگه از نو نوشته بشه.
از این به بعد دیگه باید مثل C++ خودتون مسئول مدیریت نخ هاتون باشید.
تمام توسعه های پایتون باید از اول نوشته بشن چون همشون بر پایه GIL هستن.
امکان داره مقدار زیادی سرعت رو از دست بدید!
این مورد آخر یک بار زمانی که پایتون در نسخه ی 1.5 قرار داشت آزمایش شد. یعنی GIL از مفسر حذف شد و باعث شد سرعت اجرای برنامه ای با یک نخ در پایتون به نصف سرعت قبلی برسه و چون خیلی از برنامه های پایتون از چند نخی استفاده نمی کنن این کار زیاد هم به صرفه نیست. اما امیدوارم این صحبت ها باعث نشه که فکر کنید در پایتون نمیشه از عملیات همزمانی واقعی استفاده کرد و یا فقط باید به یه CPU بسنده کرد. زبان پایتون نیازی به GIL نداره, این فقط پیاده سازی CPython که از این روش استفاده میکنه و شما توی Jython همچین چیزی رو ندارید. تو مقاله های بعدی بیشتر در مورد این زمینه ها صحبت میکنیم و راه حل های این مشکل رو مورد بررسی قرار میدیم.
اعمال هم زمان در پایتون (بخش اول)
Architecting Server/Client Convergence
In this post I argue that the current convergence of Desktop and / Web Apps (RIAs) suggests a convergence of Server and Clients and that this opens up some interesting possibilities.
I have been following an interesting series of posts by Arnon Rotem-Gal-Oz on the web/desktop convergence trend (all four posts are worth reading!). As well, in January and April, Arnon observes software converging towards:
Technologies competing for the privilege of delivering some or all of this trifecta include (but are not limited to) AJAX, Adobe Flex, Flash, Adobe Air, Microsoft Silverlight, JavaFX, Google Gears, Mozilla Prism, Aptana’s Jaxer and JNext.
These technologies are being developed in the context of increasing awareness of two trends 1) the possibilities of ‘on-tap’ cloud computing and simultaneously 2) the promise of 100’s of cores in our client computers.
Here are some observations about the current web-app situation:
What we are seeing is not just a Web/ Desktop Convergence but also the possibility of Server/Client Convergence.
This convergence has the potential to address another problem in the current state of affairs with web apps:
Actually, this is one of the drivers underlying Microsoft Volta - a technology that is designed to reduce the cost of reassigning portions of an application between server and client. However as Arnon has pointed out it does not provide an abstraction that reinforces the “coarse-grained interface” that works well in the context of the fallacies of distributed computing. Unlike Volta, tier-agnostic requests relies on the same coarse grained interface as AJAX.
Convergence of server and client technologies
However, the convergence of server and client technologies opens up the possibility for Request Based Distributed Computing and tier-agnostic requests to provide a simple mechanism for delaying architectural decisions to run-time as well as supporting:
منبع : http://www.davidpratten.com
Adaptive control of Request Based Distributed Computing
The purpose of this post is to illustrate the possibility for autonomic computing inherent in Request Based Distributed Computing (RBDC).
This is how I summarised RBDC in a recent post:
Request Based Distributed Computing is a small extension of the http protocol and notion of server, proxy and client. Rich Internet Applications, SOA architected applications and SETI@home type distributed computing alike can utilise a common unified programming model. No longer will technology dictate the locus of code execution - instead issues like availability of computing power, intellectual property and security will dictate this at run time.
This discussion focuses on the way that RBDC creates two ways to satisfy many http requests. The two ways are illustrated in the following two diagrams. These diagrams are similar to those in a earlier discussion.
In the first scenario (DIAGRAM 1) we see a client requesting resource A and evaluating code locally to satisfy its own http request.
DIAGRAM 1
In the second scenario (DIAGRAM 2) we see the same client. However in this case, when the client requests resource A, the client does not tell the server about it’s local computing capacity. In this case the relevant code is evaluated on the server.
DIAGRAM 2
The two ways of satisfying the request have differing performances. The relative performance of the two alternatives will be determined by things like the server/client balance of: response time, network bandwidth, and network latency.
A monitor can observe the time to complete each http request and recommend to the client whether to request mobile code or to let the server evaluate the code that generates the resource. This is an adaptive process because during a 24 hour period server availability, network latency and available bandwidth could change radically. Once the monitor has decided on the fastest way to execute a piece of mobile code, it may attempt the evaluation of mobile code in the opposite way once every N requests - in this way keeping its adaptive capability current.
منبع : http://www.davidpratten.com
Distributed Computing with the Browser
Recently, Subbu posted an interesting discussion of an xml analysis and presentation application - you can read it here: Distributed Computing with the Browser.
This design scenario is a good illustration of the limitations of our current situation with programming . Our current situation is that while the WWW allows a programmer to ignore the network path to an information resource, as programmers, we can’t ignore where computing will be done. The programmer’s choice of technology (framework, language etc etc) carries with it the implicit choice about the location of computation (server or client).
An assumption behind Subbu’s post is that we need to decide the location of processing during the design phase. The purpose of this post is explore how the application could be built using Request Based Distributed Computing RBDC (see backgrounder). With the application recast as a RBDC application, the location-of-processing decisions can be made at runtime based on the availability of computing power and storage, intellectual property, and security issues.
(This description presumes that you have read the RBDC backgrounder.)
The key distributed process in this application is the initial analysis of the source XML text, and the saving of the key features into a central database. Lets call this “analyse-save”. With RBDC, the code that performs analyse-save may be written as mobile code that will run on either the server, a proxy or on the client. Analyse-save may be implemented as the code that responds to a http POST request that uploads the source file to the server. It analyses the uploaded file then POSTS the results of the analysis to a central database.
When a RBDC compliant server receives the analyse-save request it may perform the analysis itself on the server or otherwise return the analyse-save code to the client. If the client receives code as a response to its analyse-post request then it would execute the code locally. In either case, the results of the analysis are POSTed to the central database using http.
Clients that have local processing capabilities signal through a http header in the POST request that they are able to accept mobile code as a response to the request. Alternatively clients without processing ability can make the same request signalling that they need the server to do all possible processing.
In this way - the architecture of the solution is the same for Subbu’s cases 1 and 3 with the decision about location of processing being made at runtime, not as part of the design.
منبع : http://www.davidpratten.com
HTC and Cloud and Grid Computing
The HyperText Computing (HTC) paradigm is not a “complete solution” to the challenges and opportunites afforded by Cloud and Grid computing — however this post argues that the HTC is part of the solution. My angle into this question is via a recent blog post.
This is how Tim Foster, in a recent post at Grid Gurus, concludes his discussion of current and future trends of Cloud and Grid computing (emphasis mine):
In building this distributed “cloud” or “grid” (“groud”?), we will need to support on-demand provisioning and configuration of integrated “virtual systems” providing the precise capabilities needed by an end-user. We will need to define protocols that allow users and service providers to discover and hand off demands to other providers, to monitor and manage their reservations, and arrange payment. We will need tools for managing both the underlying resources and the resulting distributed computations. We will need the centralized scale of today’s cloud utilities, and the distribution and interoperability of today’s grid facilities.
The concepts that Tim highlights: “on-demand provisioning”, “configuring integrated virtual systems”, providing “precise capabilities” and a focus on the needs of the “end-user” are all addressed by the HyperText Computing (HTC) paradigm. HTC also addresses the need to view central resources through the same lens as localised ones.
The HyperText Computing (or Request Based Distributed Computing - RBDC) — is a small extension of http and our conceptions of server, proxy and client. It creates a distributed computing platform that is built from an end-user perspective outwards just as http does for information. It is built on a recognition of the equivalence between http resources and the code that when executed will return the resource. RBDC unifes programming models by applying browser based sandboxed Virtual Machines (VM) to our conception of proxies and servers.
Key benefits of RBDC are ultra-lightweight distributed computing, run-time code mobility, and backwards compatibility with http.
A fuller description of RBDC may be found here.
Http offers location transparency for retrieving data, a small http extension can also provide location transparency for code execution.
منبع : http://www.davidpratten.com
The Globus Alliance has been selected as a Google Summer of Code 2008 mentoring organization. Google Summer of Code (GSoC) is a program that offers student developers stipends to write code for various open source projects. Google works with several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Historically, the program has brought together over 1,500 students with over 130 open source projects to create millions of lines of code. The program, which kicked off in 2005, is now in its fourth year. If you are a student and would be interested in participating in GSoC with Globus as your mentoring organization, please take a look at our GSoC Ideas page. This page lists projects that Globus has proposed for GSoC, but it is not a closed list. If you have an idea for a cool project that uses or extends Globus technologies, please take a look at our list of Globus GSoC mentors and contact the one which most closely matches your interests. Take into account that student proposals must be submitted by March 31st and that you must meet Google's student eligibility criteria.
If you have any questions about our participation in GSoC, please contact the Globus GSoC administrators.
منبع : http://gridgurus.typepad.com
Choosing a distributed resource management (DRM) software may not be a simple task. There are a number of open source or commercial software packages available, and companies usually go through product evaluation phase in which they consider factors like software license and support costs, maintenance issues, their own use cases and existing/planned infrastructure, etc. After following this (possibly lengthy) procedure, and finally making the decision, purchasing and installing the product, you should also make sure that the DRM software configuration fits your cluster usage and needs. In particular, designing the appropriate queue structure, configuring resources, resource management and scheduling policies are some of the most important aspects of your cluster configuration. At first glance devoting your company's resources into something like queue design might seem unnecessary. After all, how can one go wrong with the usual "short", "medium" and "long" queues? However, the bigger your organization is and the more diverse computing needs of your users are, the more likely it is that you would benefit from investing some time into designing and implementing queues more efficiently. My favorite example here involves high priority jobs that must be completed in a relatively short period of time, regardless of how busy the cluster is. Such jobs must be allowed to preempt computing resources from other lower priority jobs that are already running. Better DRMs usually allow for such use case (e.g., by configuring "preemptive scheduling" in LSF, or using "subordinated queues" in Grid Engine), but this is clearly something that has to be well thought through before it can be implemented. In any case, when configuring DRM software, it is important to keep in mind that not all jobs (or not all users for that matter) are created equal... پژوهشگران ژاپني تجهيزات نويني براي سوپر رايانه نسل آينده ساختند
توكيو - پژوهشگران وابسته به دانشگاه صنعتي توكيو و شركت الكترونيكي ان .
ايي .سي موفق به ساخت تجهيزات نويني شدند كه وجود آن براي ساخت سوپر رايانههاي نسل آينده ضروري است .
به گزارش ايرنا، روزنامه ژاپني نيهون كيزاي نوشت: كار ين تجهيزات ساخته شده ، پيوند دادن مدارهاي ال. اس. آي رايانه به يكديگر با استفاده از سيگنالهاي نوري است .
پژوهشگران در جريان يك آزمايش موفق شدند،با بهرهگيري از اين تجهيزات كه اندازه آن ۱۰سانتيمتر مربع است ، در هر ثانيه ۲۵گيگا بيت اطلاعات ارسال كنند.
اين براي نخستين بار در جهان است كه با اين شتاب فراوان اطلاعات در داخل رايانه ارسال ميشود.
به نوشته اين روزنامه، دولت ژاپن برنامه ريزي كرده است تا سال ۲۰۱۰ ميلادي سوپررايانه نسل آيندهاي را بسازد كه در هر ثانيه بتواند ۱۰پتا بار محاسبه انجام دهد و احتمال اين وجود دارد كه از اين دستاورد نوين پژوهشگران دانشگاه صنعتي توكيو و شركت ان .ايي .سي در آن استفاده شود.
هر پتا برابر با هزار تريليون است .
منبع : خبرگزاري جمهوري اسلامي
http://www1.irna.ir/fa/news/view/menu-152/8612295360091731.htm
سیستم های ردیابی و کشف نفوذ توزیع شده که با dIDS از آن یاد می کنیم،از چندین IDS در یک شبکه بزرگ تشکیل شده اند. تمامی این Intrusion Detection System ها، در ارتباط با یدیگر هستند و یا به وسیله یک سیستم (شاید یک سرور) مرکزی در حال پایش شبکه، تحلیل رویدادها و جمع آوری اطلاعات حمله های شناسایی شده، می باشند. این ترکیب برای جمع آوری اطلاعات امکان ایجاد یک دید وسیع برای تیم امنیتی/نگهدارنده شبکه در مورد وقایعی که در هر لحظه در حال جریان است را فراهم می کند.
یک distributed IDS به سازمان ها و اپراتورهای شبکه اجازه می دهد تا به صورت موثر و مستند منابع شبکه ای و سازمانی خود را تحت کنترل قرار دهند و در صورت نیاز به سرعت اطلاعات مورد نیاز را از سیستم بیرون بکشند. برای آشنایی بیشتر مقاله زیر را بخوانید:
An Introduction To Distributed Intrusion Detection Systems
Due to the greater view the agent allows the analyst to achieve, the dIDS offers the incident analyst many advantages over other single mode IDS systems. One of these advantages is the ability to detect attack patterns across an entire corporate network, with geographic locations separating segments by time zones or even continents. This could allow for the early detection of a well-planned and coordinated attack against the organization in question, which would allow the security people to ensure that targeted systems are secured and offending IPs are disallowed any access. Another proven advantage is to allow early detection of an Internet worm making its way through a corporate network. This information could then be used to identify and clean systems that have been infected by the worm, and prevent further spread of the worm into the network, therefore lowering any financial losses that would otherwise have been incurred.
تبادل اطلاعات بین IDS ها در سه گونه تقسیم بندی می شود. دسته اول محصولاتی که برای dIDS طراحی شده اند و با استفاده agentهای مختلف در نقاط مختلف شبکه اطلاعات را برای سرور کنترلی IDS ارسال می کنند. دسته دوم محصولاتی که شامل IDS هایی از یک دسته هستند و لاگ فایل های خود را در یک محل متمرکز ذخیره می کنند و مانند دسته اول ادامه کار می دهند. و بالاخره دسته سوم که شامل IDS ها و IPS های (به طور کلی آن ها را sensor خطاب می کنیم.) مختلف از مارک های متفاوتی هستند که به وسیله ابزار های مدیریت سیستم های امنیتی لاگ فایل ها را ذخیره و پردازش می کنند. استاندارد تبادل اطلاعات در سنسور ها، در قالب یک پیش نویس استاندارد IETF در حال شکل گیری است.
The Intrusion Detection Message Exchange Format (IDMEF) is intended to be a standard data format that automated intrusion detection systems can use to report alerts about events that they deem suspicious. The development of this standard format will enable interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal implementation.
به دو علت پروژه های کمی در مورد dIDS هم اکنون وجود دارد. اولین مورد عدم درک نیاز به چنین سیستمی در بخش تجاری و صنعتی و دلیل دوم نو بودن چنین ترکیبی است. همانطور که پیشتر گفتم، IDMEF هنوز به حالت استاندارد در نیامده است. البته جایگزینی این سیستم به وسیله سیستم های یکپارچه مدیریت امنیت گران قیمت نیز دلیل دیگری در کم بودن پروژه ها است. تعدادی از این پروژه ها را در freshmeat ببینید. بدنیست نگاهی هم به پروژه رو به پیشرفت Prelude Hybrid IDS ( حداقل What is Prelude Hybrid IDS را بخوانید.) بندازید.
* این مطلب مقدمه ای است برای سری نوشته های امنیت در عمق که در Secure2S بیشتر در مورد آن ها خواهید خواند. لطفا نظرات و پیشنهادات خود را در میان بگذارید. مجموعه نوشته های امنیت در عمق، تلاش خواهد کرد تا به امنیت در شبکه های بزرگ و تجاری و همچنین نکات امنیتی که کمتر به آن ها پرداخته می شود بپردازد.
منبع : http://secure2s.net/fa/1385/11/11/distributed-ids/
بیتتورنت چیست؟
بیتتورنت (BitTorrent) هم نام برنامه کاربردی مشتری بر مبنای توزیع فایل در شبکههای نظیر-به-نظیر است و هم نام یک پروتکل اشتراک فایل، که هر دو در آوریل 2001 توسط برنامهنویسی به نام برام کوهن ایجاد شدهاند. بیتتورنت به منظور توزیع حجم بزرگی از اطلاعات بدون کاهش در مصرف منابع پر هزینه سرور و پهنای باند طراحی شده است.
بیتتورنت چیست؟
اصطلاحات BitTorrent
منبع: wikipedia
تفاوت های CPU های AMD وIntel
-AMD براساس معماری اجرایی 9 مرحله ای ساخته شده است اما معماری پردازنده های Intel شش مرحله ای می باشد.بدین معنا که AMDدر هر چرخه کاری 9عملیات را انجام میدهد در حالی که Intel فقط 6 عمل را می تواند انجام دهد.
2-AMD از640Kb Cache برخوردار است در حالی که Intel ، از 532Kb بر خوردار است هر چقدر که میزان Cache پردازنده بیشتر باشد ، پردازنده کارایی بیشتری خواهد داشت اطلاعات بیشتری میتواند ذخیره کند ودیگر لازم نیست پردازنده برای بدست آوردن اطلاعات یا دستور ها مدت زمان بیشتری را رفت و برگشت به حافظه برد اصلی برای جذب اطلاعات یا دستور العمل ها صرف کند.
3- AMD از مس برای اتصال ترانزیستور های بکار رفته در پردازنده ها استفاده میکند در صورتی که در ساختمان پردازنده های Intel آلومینیوم بکار رفته است.مس هادی الکترسیته بهتری است ، ازاین رو پهنای اتصالهای بین ترانزیستورها را به میزان چشمگیری کاهش می یابد .که این امر باعث مصرف کمتر مواد اولیه و در نتیجه منجر به کاهش هزینه می شود این دلیل ارزان تر بودن AMD نسبت به P4 است.
4- از دیگر تفاوت های میان AMD و